ASF JIRA
ASF JIRA
Displaying 352 issues at 18/Mar/20 03:02.
Project Key Summary Issue Type Status Priority Resolution Assignee Reporter Creator Created Last Viewed Updated Resolved Affects Version/s Fix Version/s Component/s Due Date Votes Watchers Images Original Estimate Remaining Estimate Time Spent Work Ratio Sub-Tasks Linked Issues Environment Description Security Level Progress Σ Progress Σ Time Spent Σ Remaining Estimate Σ Original Estimate Labels Development Reviewers Ignite Flags Date of First Response Git Notification Mailing List Github Integrations - Other Github Integration Last public comment date Git Repository Name Global Rank Git Repository Type Skill Level Affects version (Component) Backport to Version Fix version (Component) Skill Level Blog Administrator? Blogs - Admin for blog Existing GitBox Approval Blogs - Username Protected Branch Blogs - Email Address GitHub Options Docs Text Git Repository Import Path New-TLP-TLPName Blogs - New Blog Write Access Blogs - Existing Blog Name Enable Automatic Patch Review Attachment count Blog - New Blog PMC Blog - New Blog Administrators Blog - Write access Epic Link Change Category Bug Category Bugzilla - List of usernames Bugzilla - PMC Name Test and Documentation Plan Bugzilla - Email Notification Address Discovered By Blogs - Existing Blog Access Level Complexity Bugzilla - Project Name Severity Bugzilla Id Level of effort Initial Confluence Contributors Target Version/s Bug behavior facts Space Name Lucene Fields Space Description Github Integration - Triggers Workaround Bugzilla Id INFRA - Subversion Repository Path Space Key Testcase included Estimated Complexity Regression Sprint Rank (Obsolete) Project Review Date Evidence Of Use On World Wide Web Evidence Of Registration Epic/Theme Flagged External issue ID Priority Reproduced In Machine Readable Info Tags Review Patch? Since Version Reviewer External issue URL Hadoop Flags Issue & fix info Evidence Of Open Source Adoption Flags Source Control Link Rank Authors Severity Tester
Commons Collections COLLECTIONS-71

Missing LICENSE in source distribution (commons-collections-1.0-src.tar.gz)

Bug Closed Blocker Fixed Unassigned Michael Marrotte Michael Marrotte 05/Mar/02 02:11 18/Mar/20 03:01 15/Mar/08 21:36 15/Mar/08 21:36 1.0       0 0   Operating System: Linux
Platform: Other
The build.xml in "commons-collections-1.0-src.tar.gz", references the
"LICENSE" file that does not exist.

This blocks a successful build of the API docs, i.e. "ant doc" as in
"README.TXT".

I "touched ../../LICENSE" for a quick fix.

--MTM
17 years, 51 weeks, 6 days ago 18927 No Perforce job exists for this issue. 0 6855 164637 0|i0sji7:
Commons Collections COLLECTIONS-23

BeanMap.putAll(beanmap) fails

Bug Closed Minor Fixed Unassigned Joe Shelby Joe Shelby 30/Jul/02 03:08 18/Mar/20 02:52 15/Mar/08 21:35 15/Mar/08 21:35 2.0       0 0   Operating System: other
Platform: Other
I created two beanmaps, both around objects of the same class, to try to
effectively clone the underlying objects (this was before I looked harder and
realized that BeanMap.clone() would try to instantiate a new object on its own).

I found that this fails with a java.lang.IllegalArgumentException: The bean of
type: com.isx.isaf.IsafAgentDescription has no property called: class

The reason: BeanMap's underlying introspector notices the read-only property of
"class" (the class of the bean object), and has a get() entry for it that has
no matching put.

When AbstractMap.putAll iterates through the values, it tries to put() the class
value and this causes the failure.

The workarounds is to reimplement putAll() outside the map and catch exceptions
for every failed put (this should be the only one unless the bean itself has
other read-only properties).

BeanMap.clone() correctly checks for read-only properties and doesn't try to
set them, but is limited to beans that have zero-parameter constructors; its
real problem is that it is still "protected" in BeanMap, not public.

Possible fix is to override putAll() from AbstractMap and check if the
property is read-only before calling put() and ignoring it if it is. Options
involving fixing put() itself would cause more problems than solutions, IMHO.

Another fix is to catch the "class" property and filter it out completely so
it never shows up in the keySet or entrySet at all.
17 years, 34 weeks, 3 days ago 18975 No Perforce job exists for this issue. 0 11262 164685 0|i0sjsv:
Commons Collections COLLECTIONS-28

SequencedHashMap.indexOf(Object key) throws annoying exceptions

Bug Closed Major Fixed Unassigned Johal Johal 18/Oct/02 16:10 18/Mar/20 02:50 15/Mar/08 21:35 15/Mar/08 21:35 2.0       0 0   Operating System: All
Platform: All
Is it intentional that SequencedHashMap.indexOf(Object key) throws a
NullPointerException when the key does not exist in the map?

Shouldn't it return -1 in those situations?

Here is an addition to the TestSequencedHashMap which examplifies the problem

public void testIndexOf() throws Exception {
Object[] keys = getKeys();
int expectedSize = keys.length;
Object[] values = getValues();
for (int i = 0; i < expectedSize; i++) {
labRat.put(keys[i], values[i]);
}
// test that the index returned are in the same order that they were
// placed in the map
for (int i=0;i<keys.length;i++) {
assertEquals("indexOf with existing key failed",i,labRat.indexOf(keys[i]));
}
// test non existing key..

assertEquals("test with non-existing key failed",-1,labRat.indexOf
("NonExistingKey"));
}
17 years, 19 weeks, 1 day ago 18970 No Perforce job exists for this issue. 0 13758 164680 0|i0sjrr:
Commons Collections COLLECTIONS-86

LRUMap.get doesn't change usage status

Bug Closed Major Fixed Unassigned Frank Finger Frank Finger 17/Oct/02 14:48 18/Mar/20 02:50 15/Mar/08 21:36 15/Mar/08 21:36 2.0       0 0   Operating System: All
Platform: PC
LRUMap drops the least resently added item, not the least recently used one. The
following test fails in line 6 (and 7, if you comment out 6).


1: LRUMap map = new LRUMap( 2 );
2: map.put( "2", "zwei" );
3: map.put( "3", "drei" );

4: map.get( "2" ); // now, "2" should be least recently used
5: map.put( "4", "vier" ); // this should drop "3"

6: assertEquals( "zwei", map.get("2") );
7: assertEquals( null, map.get("3") );
8: assertEquals( "vier", map.get("4") );
17 years, 24 weeks, 5 days ago 18912 No Perforce job exists for this issue. 0 13722 164622 0|i0sjev:
Commons Collections COLLECTIONS-103

SoftRefHashMap is all kinds of wonky

Bug Closed Major Fixed Unassigned Paul Jack Paul Jack 03/Jun/02 13:12 18/Mar/20 02:51 14/Jul/06 05:45 14/Jul/06 05:33 2.0 2.1     1 0   Operating System: All
Platform: All
Many methods in SoftRefHashMap do not conform the the java.util.Map
specification. After you populate a SoftRefHashMap using its put or putAll
method, it transforms the values into SoftReferences. The get() method
correctly re-translates the SoftReferences back into the actual object values,
unless they've been garbage collected.

However, the entrySet() collection view does NOT perform this reverse
translation; iterating over an entry set gives you Map.Entry with SoftReference
values. Since the equals() and hashCode() methods rely on iterating over the
entry set, equals() and hashCode() are broken in SoftRefHashMap.

Also, it's odd that after I put(key,value), containsValue(value) will return
true, yet I won't be able to find the value in the entry set.

Also, invoking setValue() on a Map.Entry in the entrySet will correctly update
the map with a new value; however, the old value is not returned as per the Map
specification.

Also, the values() and entrySet() collection views are not backed by the map;
alterations to the map are not reflected in any existing values() or entrySet()
collection views.

Also, containsKey(Object) is wierd. If I put(key,value), and the value is
subsequently garbage collected, containsValue(value) will return false, yet
containsKey(key) will still return true.

Creating a values() collection view creates hard references to the map's
values, essentially ruining the point of the class (so long as the values()
collection view exists, the map does not function as a memory-aware cache).

Finally, iterating over keySet() and entrySet() is wonky. Mappings might have
been removed by the garbage collector, but the iterators will still return an
object for the mapping. So keySet()'s iterator will return keys for values
that aren't there anymore, and entrySet()'s iterator will return Map.Entries
with keys that map to null instead of values.
17 years, 34 weeks, 1 day ago 18895 No Perforce job exists for this issue. 0 9571 164605 0|i0sjb3:
Commons Collections COLLECTIONS-385

Inconsistent Javadoc comment and code in addAll(Collection, Object[]) in org.apache.commons.collections.CollectionUtils

Bug Closed Major Not A Problem Unassigned SHIN HWEI TAN SHIN HWEI TAN 26/Oct/11 20:27 18/Mar/20 02:54 27/Nov/15 21:47 26/Jul/12 21:06 2.1, 2.1.1, 3.0, 3.1, 3.2   Collection   0 0 300 300 0% Platform Independent The Javadoc comment below states that the method "throws NullPointerException if the collection or array is null".
/**
* Adds all elements in the array to the given collection.
*
* @param collection the collection to add to, must not be null
* @param elements the array of elements to add, must not be null
* @throws NullPointerException if the collection or array is null
*/
public static void addAll(Collection collection, Object[] elements) {
for (int i = 0, size = elements.length; i < size; i++) {
collection.add(elements[i]);
}
}

However, when called with an empty array and a null collection (i.e., "addAll((Collection)null, new Object[])"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if the collection or array is null" from the Javadoc.
or
3. Change "@throws NullPointerException if the collection or array is null" to "@throws NullPointerException if the array is null or (the array is non-empty and the collection is null)".
0% 0% 300 300 javadoc, nullpointerexception
8 years, 21 weeks, 3 days ago 214816 No Perforce job exists for this issue. 0 164370 0|i0shuv:
Commons Collections COLLECTIONS-6

[Collections] - MapUtils]Method to generate a Map from a Object[][]

Bug Closed Major Fixed Unassigned Rafael U. C. Afonso Rafael U. C. Afonso 27/Aug/04 08:02 18/Mar/20 02:51 15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: other
Platform: Other
In Python Language it is possible create a dictionary (equivalent to Map) using
only a single line:

myMap = {'alpha':'a', 'betha':'b', 'gamma':'c'}

In Java it is not possible. We must do it "manually":

Map myMap = new HashMap();
myMap.put("alpha", "a");
myMap.put("betha", "b");
myMap.put("gamma", "c");

My propose is create a way to do this with less burocracy. In
org.apache.commons.collections.MapUtils class could have a method called
fillMap (or better name) that receives a Map and a bi-dimentional array of
Objects. It will work like this:

public static Map fillMap(Map map, Object[][] keyValue) {
for(int i = 0; i < keyValue.length; i ++) {
map.put(keyValue[i][0], keyValue[i][1]);
}
return map;
}

So, returning to prior example, we could do this:

Map myMap = MapUtils.fillMap(new HashMap(), {{"alpha", "a"}, {"betha", "b"},
{"gama", "c"}});

Or to put in mass in a pre-existent MAP:

MapUtils.fillMap(myMap, {{"delta", "d"}, {"epslon", "e"}, {"omega", "z"}});
15 years, 27 weeks, 5 days ago 18992 No Perforce job exists for this issue. 1 30882 164702 0|i0sjwn:
Commons Collections COLLECTIONS-55

[collections] Filling out PredicatedXXX Javadoc - a functor package.html

Bug Closed Major Fixed Unassigned Tim O'Brien Tim O'Brien 16/May/04 09:30 18/Mar/20 02:51 15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: other
Platform: Other
In general Predicated collections and maps should probably be created before a
data structure has any contents. Maybe this is just an artifact of the way I
use PredicatedList, but, nevertheless, I think all of the PredicatedXXX
classes need fuller JavaDoc - possibly pointing to an anchor in the
package.html for the functors package that talks about some scenarios for
using PredicatedXXX classes. Right now we don't have a good in JavaDoc
explanation of the various ways to apply a Predicate to a collection.

(I'm on a Javadoc kick, sorry.)
15 years, 45 weeks, 3 days ago 18943 No Perforce job exists for this issue. 0 29018 164653 0|i0sjlr:
Commons Collections COLLECTIONS-100

[collections] IteratorChain bug with empty iterators.

Bug Closed Major Incomplete Unassigned Andrus Adamchik Andrus Adamchik 03/Dec/03 13:11 18/Mar/20 02:51 15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: All
Platform: All
Haven't tried this with nightly builds, but 2.1 collections have the follwoing
problem: when the first iterator in a chain is empty, first call to "hasNext"
returns false, on second and subsequent calls, "true" is returned again as it
should. Here is an example:

List emptyList = new ArrayList();
List nonEmptyList = new ArrayList();
nonEmptyList.add(new Object());

IteratorChain it = new IteratorChain(new Iterator[]
{emptyList.iterator(), nonEmptyList.iterator()});
System.out.println("Next? " + it.hasNext()); // prints false
System.out.println("Next again? " + it.hasNext()); // prints true

Cheers,
Andrus
16 years, 17 weeks, 4 days ago 18898 No Perforce job exists for this issue. 0 25154 164608 0|i0sjbr:
Commons Collections COLLECTIONS-80

[Patch] [Collections] ExtendedProperties.interpolate does not do recursive substitution

Bug Closed Major Fixed Unassigned hoschek hoschek 16/Dec/03 12:15 18/Mar/20 02:51 15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: other
Platform: Other
[Patch] [Collections] ExtendedProperties.interpolate does not do recursive
substitution in commons-collections-2.1, but it probably should, when used with
getString(...).

Example:

firefish.home=/tmp/firefish
database.dir=${firefish.home}/samples/cfengine
database.file=${database.dir}/db.xml

extendedProps.getString("database.file")

I found out that this can be fixed with the patch below, which is simply a copy
and paste from the CVS of org.apache.commons.configuration.AbstractConfiguration.

/**
* interpolate key names to handle ${key} stuff
*
* @param base string to interpolate
*
* @return returns the key name with the ${key} substituted
*/
protected String interpolate(String base)
// copied from org.apache.commons.configuration.AbstractConfiguration
{
return (interpolateHelper(base, null));
}

/**
* Recursive handler for multple levels of interpolation.
*
* When called the first time, priorVariables should be null.
*
* @param base string with the ${key} variables
* @param priorVariables serves two purposes: to allow checking for
* loops, and creating a meaningful exception message should a loop
* occur. It's 0'th element will be set to the value of base from
* the first call. All subsequent interpolated variables are added
* afterward.
*
* @return the string with the interpolation taken care of
*/
protected String interpolateHelper(String base, List priorVariables)
// copied from org.apache.commons.configuration.AbstractConfiguration
{
if (base == null)
{
return null;
}

// on the first call initialize priorVariables
// and add base as the first element
if (priorVariables == null)
{
priorVariables = new ArrayList();
priorVariables.add(base);
}

int begin = -1;
int end = -1;
int prec = 0 - END_TOKEN.length();
String variable = null;
StringBuffer result = new StringBuffer();

// FIXME: we should probably allow the escaping of the start token
while (((begin = base.indexOf(START_TOKEN, prec + END_TOKEN.length()))
> -1)
&& ((end = base.indexOf(END_TOKEN, begin)) > -1))
{
result.append(base.substring(prec + END_TOKEN.length(), begin));
variable = base.substring(begin + START_TOKEN.length(), end);

// if we've got a loop, create a useful exception message and throw
if (priorVariables.contains(variable))
{
String initialBase = priorVariables.remove(0).toString();
priorVariables.add(variable);
StringBuffer priorVariableSb = new StringBuffer();

// create a nice trace of interpolated variables like so:
// var1->var2->var3
for (Iterator it = priorVariables.iterator(); it.hasNext();)
{
priorVariableSb.append(it.next());
if (it.hasNext())
{
priorVariableSb.append("->");
}
}

throw new IllegalStateException(
"infinite loop in property interpolation of "
+ initialBase
+ ": "
+ priorVariableSb.toString());
}
// otherwise, add this variable to the interpolation list.
else
{
priorVariables.add(variable);
}

//QUESTION: getProperty or getPropertyDirect
Object value = getProperty(variable);
if (value != null)
{
result.append(interpolateHelper(value.toString(),
priorVariables));

// pop the interpolated variable off the stack
// this maintains priorVariables correctness for
// properties with multiple interpolations, e.g.
// prop.name=${some.other.prop1}/blahblah/${some.other.prop2}
priorVariables.remove(priorVariables.size() - 1);
}
else if (defaults != null && defaults.getString(variable,
null) != null)
{
result.append(defaults.getString(variable));
}
else
{
//variable not defined - so put it back in the value
result.append(START_TOKEN).append(variable).append(END_TOKEN);
}
prec = end;
}
result.append(base.substring(prec + END_TOKEN.length(), base.length()));

return result.toString();
}
16 years, 14 weeks, 1 day ago 18918 No Perforce job exists for this issue. 0 25553 164628 0|i0sjg7:
Commons Collections COLLECTIONS-21

TestMap.tearDown() should throw Exception

Bug Closed Minor Fixed Unassigned Rich Dougherty Rich Dougherty 01/Nov/02 07:20 18/Mar/20 02:51 15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: other
Platform: All
TestMap.tearDown() overrides TestCase.tearDown(). The original method throws an
Exception, however the redeclared method doesn't. This means that methods which
override TestMap.tearDown() cannot throw an Exception. In my case, I'm creating
and removing a test database in the setUp() and tearDown() so an Exception could
easily be thrown.

I realise that TestMap isn't part of Collections' public API, however I thought
I'd mention this in case other people want to reuse your excellent testing code.
17 years, 22 weeks, 3 days ago 18977 No Perforce job exists for this issue. 0 14151 164687 0|i0sjtb:
Commons Collections COLLECTIONS-128

[collections] IteratorChain - if first iterator empty, doesn't care about next ones.

Bug Closed Major Fixed Unassigned Pawel Stawicki Pawel Stawicki 10/Jan/04 21:27 18/Mar/20 02:51 15/Mar/08 21:36 14/Jul/06 12:04 2.1       1 0   Operating System: All
Platform: PC
If first Iterator in IteratorChain is empty, and next ones contain some
elements, first call to hasNext() on IteratorChain returns false. It should
return true if there are elements in other Iterators.
13 years, 37 weeks, 4 days ago 18870 No Perforce job exists for this issue. 0 26038 164580 0|i0sj5j:
Commons Collections COLLECTIONS-96

debug and verbose print in MapUtils only handles String keys

Bug Closed Major Fixed Unassigned Matt Gould Matt Gould 14/Jan/04 10:22 18/Mar/20 02:51 15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: other
Platform: All
In MapUtils, if the key is e.g., Integer, fails with a ClassCastException:

for ( Iterator iter = map.entrySet().iterator(); iter.hasNext(); ) {
Map.Entry entry = (Map.Entry) iter.next();
==> String childKey = (String) entry.getKey();
Object childValue = entry.getValue();
if ( childValue instanceof Map ) {
verbosePrint( out, childKey, (Map) childValue );
}

Should not be cast to a String, just use Object, and it works.
Same thing goes for the less verbose sister method, debugPrint
Thanks,
Matt
16 years, 11 weeks, 5 days ago 18902 No Perforce job exists for this issue. 0 26115 164612 0|i0sjcn:
Commons Collections COLLECTIONS-50

[collections] ExtendedProperties combine and pre unescaped strings-values

Bug Closed Major Won't Fix Unassigned Dean Arnold Dean Arnold 20/Nov/03 17:42 18/Mar/20 02:51 15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: other
Platform: All
If you have 2 extended props (prop1 & prop2). prop1 contains some or none
key/value pairs and prop2 contains at least one key with string value with
commas that doesn't already exist in prop1. N.B. This assumes both props were
loaded from property files and the string values in prop2 were escaped in the
file-system properties.

If you call prop1.combine(prop2), the string-value from prop2 that contained
commas is treated as a non-escaped string and thus broken down into a Vector in
prop1. It should put the string-value into prop1 without procing the commas as
there were already processed by prop2 when it was loaded.

I believe that the combine method should merge the existing values from both
props and the putAll method should be overidden to overite existing keys in
prop1 from prop2 while maintaining the keysAsListed List.
16 years, 3 weeks, 2 days ago 18948 No Perforce job exists for this issue. 0 24849 164658 0|i0sjmv:
Commons Collections COLLECTIONS-82

[collections] Map.debugPrint improvements

Bug Closed Major Fixed Unassigned Max Rydahl Andersen Max Rydahl Andersen 13/Jun/03 18:07 18/Mar/20 02:51 15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: other
Platform: Other
debugPrint and verbosePrint in MapUtils makes a cast of the key to a string
(instead of calling toString() on it) which makes it impossible to use for debug
printin maps with keys other than strings.
16 years, 31 weeks, 2 days ago 18916 No Perforce job exists for this issue. 5 20740 164626 0|i0sjfr:
Commons Collections COLLECTIONS-120

BeanMap.toString() causes infinite loop on circular object graph

Bug Closed Major Fixed Unassigned _matthewHawthorne _matthewHawthorne 17/Apr/03 04:46 18/Mar/20 02:51 15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: Linux
Platform: Other
This problem is similar to the one in [lang]'s ToStringBuilder.
16 years, 50 weeks, 3 days ago 18878 No Perforce job exists for this issue. 1 19096 164588 0|i0sj7b:
Commons Collections COLLECTIONS-2

[collections] ExtendedProperties.save(...) does not escape special characters

Bug Closed Major Fixed Unassigned Dariusz Wojtas Dariusz Wojtas 16/Apr/03 18:28   15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: All
Platform: PC
If some value ends with '\', then after saving it, load will fail or will have
incorrect values.
Try to store some property with value ending with '\', eg.

path1=e:\
path2=c:\docs

Look for java.util.Properties on escaping characters.
16 years, 32 weeks, 2 days ago 18996 No Perforce job exists for this issue. 1 19061 164706 0|i0sjxj:
Commons Collections COLLECTIONS-40

ExtendedProperties.load should default to encoding "8859_1"

Bug Closed Major Fixed Unassigned Kirk Wolf Kirk Wolf 04/Mar/03 03:47   15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: All
Platform: All
The default load method for commons.collections.ExtendedProperties currently
loads properties using the default JVM encoding. The default load() method
should use "8859_1" encoding.

Rationale:
1) consistency: java.util.Properties.load() method always uses "8859_1"
2) properties resources are always 8859_1, by convention.
2) On edbcic machines, particularly IBM mainframes, the default encoding is
Cp1047 (ebcdic), but properties files are always ASCII (ISO8859-1)
3) This bug causes many Apache tools, such as Velocity, which uses
commons.collections, to fail on non-ascii machines, since they distribute
properties resources which are (correctly) in 8859-1.
16 years, 50 weeks, 3 days ago 18958 No Perforce job exists for this issue. 1 17616 164668 0|i0sjp3:
Commons Collections COLLECTIONS-105

StaticBucketMap.remove(Object) incorrectly handles key comparison

Bug Closed Major Fixed Unassigned leo.sutic leo.sutic 18/Feb/03 02:15   15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: other
Platform: Other
I've found a bug in the StaticBucketMap class, the remove(Object)
method:

/**
* Implements {@link Map#remove(Object)}.
*/
public Object remove( Object key )
{
int hash = getHash( key );

synchronized( m_locks[ hash ] )
{
Node n = m_buckets[ hash ];
Node prev = null;

while( n != null )
{
HERE>>>>>>>>> if( n.key == null || ( n.key != null && n.key.equals(
key ) ) ) <<<<<<<<<<<<<<<<<<
{
// Remove this node from the linked list of nodes.
if( null == prev )
{
// This node was the head, set the next node to
be the new head.
m_buckets[ hash ] = n.next;
}
else
{
// Set the next node of the previous node to be
the node after this one.
prev.next = n.next;
}
m_locks[hash].size--;
return n.value;
}

prev = n;
n = n.next;
}
}

return null;
}

The test is:

if( n.key == null || ( n.key != null && n.key.equals(
key ) ) )

should be:

if( n.key == key || ( n.key != null && n.key.equals( key
) ) )

which is how it works in get(Object), containsKey(Object) etc. and which
is correct. We have a match if the keys match using == OR if they are
equal according to equals().
17 years, 6 weeks, 3 days ago 18893 No Perforce job exists for this issue. 0 17139 164603 0|i0sjan:
Commons Collections COLLECTIONS-91

[collections] CollectionWrapper should implement Serializable

Bug Closed Minor Duplicate Unassigned sean schofield sean schofield 18/Nov/03 05:22   15/Mar/08 21:36 14/Jul/06 12:07 2.1       1 0   Operating System: All
Platform: All
The CollectionWrapper inner class (part of CollectionUtils) should implement
Serializable. This would allow the creation of serializable lists in the event
that the user needs this functionality. Making this change would assume that
all the objects contained in the list were serializable (not a big deal IMO.)

I discovered this problem when using ListUtils.lazyList() method. The
resulting list is not serializable and I need it to be.
13 years, 37 weeks, 4 days ago 18907 No Perforce job exists for this issue. 0 24762 164617 0|i0sjdr:
Commons Collections COLLECTIONS-62

ReferenceMap contract

Bug Closed Major Fixed Unassigned Eduardo Francos Eduardo Francos 27/Nov/02 17:50   15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: All
Platform: All
I switched from SoftRefHashMap to ReferenceMap and I noticed that the purge
method as become private and is called in many places in the source code, but
the documentation for the method states that it is called only for write operations.
I must be sure that the stale mappings are removed for read operations too
(ex:size) and though currently the implementation calls purge() for all read
methods as well this may change in the future.
I think that calling purge on all [relevant] public methods is the right
approach to preserve a coherent state.
17 years, 10 weeks, 3 days ago 18936 No Perforce job exists for this issue. 0 14889 164646 0|i0sjk7:
Commons Collections COLLECTIONS-73

BeanMap.putAllWriteable() does not count the write only methods

Bug Closed Major Fixed Unassigned Dimiter Dimitrov Dimiter Dimitrov 09/Jan/03 02:26   15/Mar/08 21:36 15/Mar/08 21:36 2.1       0 0   Operating System: All
Platform: All
BeanMap.putAllWriteable(BeanMap) method, the java doc does not describe the implementation
correctly.
According to Sun a property could be defined by getter OR mutator. The current
implementation of the method assumes that a property always should have getter.

/**
*
Puts all of the writeable properties from the given BeanMap into this
* BeanMap. Read-only
properties will be ignored.
*/
public void putAllWriteable(BeanMap map) {
Iterator
readableKeys = map.readMethods.keySet().iterator();
while(readableKeys.hasNext())
{
Object key = readableKeys.next();
if(getWriteMethod(key) != null) {
this.put(key,
map.get(key));
}
}
}


I have an adapter bean which have a mutator which accepting a
long value (actualy a bit vector) And few boolean accessors which retrieve the actual values.
Now I'm replacing my own utility classes with jakarta commons and I find that these issues make
them nearly unusable for me :(

I suggest to change the method to:

public void
putAllWriteable(BeanMap map) {
Iterator writableEntries =
map.writeMethods.entrySet().iterator();
while(writableEntries.hasNext()){

Map.Entry writableEntry = (Map.Entry) writableEntries.next();

writeMethods.put(writableEntry.getKey(), writableEntry.getValue());
}
}
17 years, 10 weeks, 3 days ago 18925 No Perforce job exists for this issue. 1 15897 164635 0|i0sjhr:
Commons Collections COLLECTIONS-22

[collections] In BeanMap all properties are writable (some with null mutator)

Bug Closed Major Fixed Unassigned Dimiter Dimitrov Dimiter Dimitrov 09/Jan/03 01:24   15/Mar/08 21:35 15/Mar/08 21:35 2.1       0 0   Operating System: All
Platform: All
In BeanMap.initialize() method there is a bug that causes all properties to have write methods
(even if they are null).
15 years, 1 week, 6 days ago 18976 No Perforce job exists for this issue. 1 15895 164686 0|i0sjt3:
Commons Collections COLLECTIONS-734

Encountered an IllegalStateException while traversing with Flat3Map.entrySet()

Bug Resolved Major Fixed Unassigned Chen Chen 11/Nov/19 08:07   05/Dec/19 16:13 05/Dec/19 16:13 3.0 4.5 Map   0 1 0 1200   Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java}
//代码示例
public void testEntrySet() {
final Flat3Map<Integer, String> map = new Flat3Map<>();
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
Iterator<Map.Entry<Integer, String>> it = map.entrySet().iterator(); Map.Entry<Integer, String> mapEntry1 = it.next();
Map.Entry<Integer, String> mapEntry2 = it.next();
Map.Entry<Integer, String> mapEntry3 = it.next();
it.remove(); assertEquals(2, map.size());
}
{code}
Using the above code will generate an IllegalStateException.
The reason for this problem is that there is a problem with the EntryIterator.remove() method in the Flat3Map java class.


I submitted a [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115) to fix this bug.
100% 100% 1200 0
14 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z08gjk:
Commons Collections COLLECTIONS-580

Arbitrary remote code execution with InvokerTransformer

Bug Closed Major Fixed Unassigned Philippe Marschall Philippe Marschall 07/Nov/15 13:28 18/Mar/20 02:57 24/Jul/19 18:56 21/Nov/15 10:02 3.0, 4.0 3.2.2, 4.1     66 104   With {{InvokerTransformer}} serializable collections can be build that execute arbitrary Java code. {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes {{#entrySet}} and {{#get}} on a deserialized collection. If you have an endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you can combine the two to create arbitrary remote code execution vulnerability.

I don't know of a good fix short of removing {{InvokerTransformer}} or making it not Serializable. Both probably break existing applications.

This is not my research, but has been discovered by other people.

https://github.com/frohoff/ysoserial

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
4 years, 15 weeks ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807 0|i2o3kf:
Commons Collections COLLECTIONS-581

Deserialization and Apache Commons Collection

Bug Closed Major Invalid Mark Thomas Deepesh Deepesh 10/Nov/15 09:55 18/Mar/20 02:55 27/Nov/15 21:47 10/Nov/15 10:00 3.0, 3.1, 3.2.1   Functor   0 1   Hi Team,

This is regarding “commons-collections Java library”. In our applications we are widely using this library and hence looking to urgently patch the fix for vulnerability issue if it is available.
Searching on internet we found one patch released on Sunday 08th Nov http://svn.apache.org/viewvc?view=revision&revision=1713307

Just wanted to check with you if there is any updated / complied version of commons-collections jar available or going to be released soon which we can directly replace with our existing jar file that provides the fix for the vulnerability issue.

Thanks in advance!
patch
4 years, 19 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Patch, Important
0|i2o6qn:
Commons Collections COLLECTIONS-384

Inconsistent Javadoc comment and code for synchronizedMap(Map) in org.apache.commons.collections.MapUtils

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 26/Oct/11 20:21 18/Mar/20 02:41 09/Nov/14 14:31 29/Oct/11 20:54 3.0, 3.1, 3.2 4.0-alpha1, 4.0 Collection   0 0 300 300 0% Platform independent The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
...
* @param map the map to synchronize, must not be null
* @return a synchronized map backed by the given map
* @throws IllegalArgumentException if the map is null
*/
public static Map synchronizedMap(Map map) {
return Collections.synchronizedMap(map);
}

However, the method throws NullPointerException instead of IllegalArgumentException when called with null.

Suggested Fixes:
1. Add code "if (map == null) throw IllegalArgumentException();" at the beginning of the method body.
or
2. Change "@throws IllegalArgumentException if the map is null" to "@throws NullPointerException if the map is null".
or
3. Remove the entire "@throws IllegalArgumentException if the map is null".
0% 0% 300 300 code, javadoc, synchronizedMap 8 years, 21 weeks, 3 days ago 214815 No Perforce job exists for this issue. 0 164371 0|i0shv3:
Commons Collections COLLECTIONS-352

AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter

Bug Closed Minor Fixed Unassigned Adam Gent Adam Gent 10/Feb/10 20:34   09/Nov/14 14:31 28/Feb/13 20:05 3.0, 3.1, 3.2 4.0-alpha1, 4.0 Collection   0 1   AbstractListDecorator uses getList() to access its private member variable for its methods:
{code}
public int indexOf(Object object) {
return getList().indexOf(object);
}
{code}

Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor):

{code}
public static class FutureList<T> extends AbstractListDecorator {

private Future<List<T>> futureList;

public FutureList(Future<List<T>> futureList)
{
super();
this.futureList = futureList;
}

@Override
protected Collection<T> getCollection()
{
try
{
return futureList.get();
}
catch (InterruptedException e)
{
throw new RuntimeException(e);
}
catch (ExecutionException e)
{
throw new RuntimeException(e);
}
}
}
{code}

But AbstractCollectionDecorator uses its private member variable
{code}
public boolean add(Object object) {
return collection.add(object);
}
{code}

When it should be IMHO:

{code}
public boolean add(Object object) {
return getCollection().add(object);
}
{code}

Of course most everybody has an armpit and an opinion :)
9 years, 40 weeks, 3 days ago 18651 No Perforce job exists for this issue. 0 164393 0|i0shzz:
Commons Collections COLLECTIONS-98

[collections] BlockingBuffer Should Include Cause Exception When Throwing BufferUnderflowException

Bug Closed Major Fixed Unassigned Seth Ladd Seth Ladd 23/Feb/05 06:22   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: All
Platform: All
The code for BlockingBuffer throws BufferUnderflowException when a
InterruptedException is thrown. But, the original InterruptedException is not
included or wrapped by the new BufferUnderflowException. This makes it
difficult to determine if the thread was truly interrupted.

I believe the commons project has support for wrapping exception (to support
older JVMs). This would be very helpful to support.

For instance, line 141 of the 3.0 version of BlockingBuffer.

Thanks!
14 years, 46 weeks, 1 day ago 18900 No Perforce job exists for this issue. 0 33700 164610 0|i0sjc7:
Commons Collections COLLECTIONS-118

[collections] LRUMap.removeLRU(LinkEntry) is passed wrong link entry

Bug Closed Major Fixed Unassigned meurig sage meurig sage 16/Apr/04 20:51   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: Windows XP
Platform: PC
The following program attempts to add 3 entries (a,b,c) to an LRUMap with max
size two.

The contents of the LRUMap are always correct but when the LRUMap fills up it
removes entry "a" but passes entry "b" to the removeLRU method.

run:
[java] [a]
[java] [a, b]
[java] Remove lru b
[java] [b, c]

import org.apache.commons.collections.map.LRUMap;

public class LRUMapTest {
public static void main (String[] args) {
LRUMap map = new LRUMap(2) {
protected boolean removeLRU(LinkEntry entry) {
System.out.println("Remove lru "+entry.getKey());
return true;
}
};
map.put("a","a");
System.out.println(map.keySet());
map.put("b","b");
System.out.println(map.keySet());
map.put("c","c");
System.out.println(map.keySet());
}
}
15 years, 50 weeks, 3 days ago 18880 No Perforce job exists for this issue. 0 28433 164590 0|i0sj7r:
Commons Collections COLLECTIONS-115

Flat3Map doesn't implement Serializable

Bug Closed Major Fixed Unassigned Manik Surtani Manik Surtani 25/Mar/04 22:39   14/Jul/06 05:44 14/Jul/06 05:44 3.0 3.1     0 0   Operating System: Linux
Platform: All
A very useful hish performance map. Sadly I cannot use it in my J2EE env
because it isn't seriabilable and hence cannot be a parameter in any remote calls.

Is there a specific reason as to why this isn't Serializable, or was this
something that was overlooked?
16 years, 4 days ago 18883 No Perforce job exists for this issue. 0 27946 164593 0|i0sj8f:
Commons Collections COLLECTIONS-32

[collections] DualTreeBidiMap does not sort with custom Comparator

Bug Closed Major Fixed Unassigned Jonas Van Poucke Jonas Van Poucke 11/Jun/04 15:47   15/Mar/08 21:35 15/Mar/08 21:35 3.0 3.1     0 0   Operating System: other
Platform: Other
When you supply a Comparator to the constructor of DualTreeBidiMap, the custom
sorting order is NOT maintained.

The problem lies in the order where
protected Map createMap()
is called: The constructors in AbstractDualBidiMap call this metod, but the
comparator is set *after* calling super() in DualTreeBidiMap:

//--- Class AbstractDualBidiMap---//
protected AbstractDualBidiMap() {
super();
maps[0] = createMap();
maps[1] = createMap();
}
//--- Class DualTreeBidiMap ---//
public DualTreeBidiMap(Comparator comparator) {
super();
this.comparator = comparator; // <-- Too late, createMap already called!
}
protected Map createMap() {
return new TreeMap(comparator); // <-- Comparator always null
}


Hence, DualTreeBidiMap.compatator() always returns null.
15 years, 42 weeks, 1 day ago 18966 No Perforce job exists for this issue. 0 29519 164676 0|i0sjqv:
Commons Collections COLLECTIONS-81

[collections] Open Patch 25553 for version 3.0

Bug Closed Major Incomplete Unassigned Stefan DAMIAN Stefan DAMIAN 07/Jun/04 19:46   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: other
Platform: Other
Patch 25553 wasn't corrected in collection - final version 3.0
14 years, 40 weeks, 3 days ago 18917 No Perforce job exists for this issue. 0 29423 164627 0|i0sjfz:
Commons Collections COLLECTIONS-130

[collections] CollectionUtils.cardinality should be made smarter about Bag

Bug Closed Major Fixed Unassigned Jon Schewe Jon Schewe 27/Apr/04 21:37   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: other
Platform: Other
I see that Bag implementations have a getCount() method that one would presume
is more efficient than iterating over the objects in the Collection. Why
doesn't CollectionUtils.cardinality() take advantage of this?
15 years, 48 weeks, 6 days ago 18868 No Perforce job exists for this issue. 0 28629 164578 0|i0sj53:
Commons Collections COLLECTIONS-24

[collections] [patch] TransformingPredicate

Bug Closed Major Fixed Unassigned Alban Peignier Alban Peignier 15/Feb/04 05:47   15/Mar/08 21:35 15/Mar/08 21:35 3.0       0 0   Operating System: other
Platform: Other
A Predicate which transforms the given object before evaluating the result with
another Predicate :

public boolean evaluate(Object object) {
Object result = transformer.transform(object);
return predicate.evaluate(result);
}
16 years, 3 weeks, 3 days ago 18974 No Perforce job exists for this issue. 1 26946 164684 0|i0sjsn:
Commons Collections COLLECTIONS-27

[collections] LRUMap.clone() broken?

Bug Closed Major Fixed Unassigned Fabrizio Giustina Fabrizio Giustina 23/Feb/04 22:21   15/Mar/08 21:35 15/Mar/08 21:35 3.0       0 0   Operating System: other
Platform: Other
LRUMap.clone() always produces an empty Map. Shouldn't it produce a shallow
copy with all the entries?

This test actually fails in 3.0:

public void testLRUMapClone()
{
LRUMap lru = new LRUMap(10);
lru.put("1", "1");

Map lruClone = (Map) lru.clone();

assertEquals(lru.size(), lruClone.size());
}
16 years, 5 weeks, 4 days ago 18971 No Perforce job exists for this issue. 0 27159 164681 0|i0sjrz:
Commons Collections COLLECTIONS-95

[collections] fails the method TransformedMap.transformedMap

Bug Closed Major Fixed Unassigned Tirso Canela Tirso Canela 31/Aug/04 19:41   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: other
Platform: Other
This methods instance a TransformedMap but it doesn't do anything.
The method transformMap must be called internally.
14 years, 37 weeks, 3 days ago 18903 No Perforce job exists for this issue. 1 30959 164613 0|i0sjcv:
Commons Collections COLLECTIONS-132

Input streams are never closed in ExtendedProperties

Bug Closed Major Fixed Unassigned Lars Beuster Lars Beuster 17/Mar/04 20:59   15/Mar/08 21:36 15/Mar/08 21:36 3.0       0 0   Operating System: other
Platform: Other
If I read a file with ExtendedProperties the OS cannot remove this file as long
as my JVM is running because it has still a handle on that file.
16 years, 2 weeks, 5 days ago 18866 No Perforce job exists for this issue. 0 27737 164576 0|i0sj4n:
Commons Collections COLLECTIONS-599

HashEntry array object naming data initialized with double the size during deserialization

Bug Closed Critical Fixed Unassigned Tejas Patel Tejas Patel 02/Dec/16 11:58   05/Jul/19 15:47 05/Jul/19 15:47 3.1 4.1 Collection, Map   0 4   Common collections 3.1 and 3.2 are used at many places and frameworks including struts2.
Supose a LinkedMap object it is created and have size greater than zero is serialized. While deserializing this object , array of HashEntry naming data delacred in AbstractHashedMap always initialises with a new capacity of double its double of the serialized object.

Please see the below API declared in AbstractHashedMap class :

{code:java}
protected void checkCapacity()
{
if (this.size >= this.threshold)
{
int newCapacity = this.data.length * 2;
if (newCapacity <= 1073741824) {
ensureCapacity(newCapacity);
}
}
}
{code}
2 years, 6 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Important
0|i372nr:
Commons Collections COLLECTIONS-358

CollectionUtils.removeAll(Collection collection, Collection remove) calls ListUtils.retainAll(collection, remove)

Bug Closed Major Duplicate Unassigned Andreas Knees Andreas Knees 29/Jun/10 21:35   29/Jun/10 23:38 29/Jun/10 23:38 3.1   Collection   0 0   any Inside CollectionUtils.removeAll(Collection collection, Collection remove) the retainAll() method of ListUtils is called in line 1122.
It should read ListUtils.removeAll(collection, remove) instead.

Workaround: use ListUtils.removeAll(Collection collection, Collection remove) instead.
9 years, 39 weeks ago 18645 No Perforce job exists for this issue. 0 164389 0|i0shz3:
Commons Collections COLLECTIONS-250

containsKey on MultiHashMap seems incorrect

Bug Closed Critical Invalid James Carman Nikhil G. Daddikar Nikhil G. Daddikar 27/Apr/07 10:24   15/Mar/08 21:36 30/Apr/07 10:56 3.1, 3.2   Map   0 2  
MultiHashMap m = new MultiHashMap();
m.putAll("key", Collections.EMPTY_LIST);
System.out.println(m.containsKey("key"))

It says false, when it should have printed true.

The problem is that the code in MultiHashMap and even MultiValueMap has in putAll():

if (values == null || values.size() == 0)
{
return false;
}

This means that they key is never being entered into the Map. This is causing a huge problem because the behaviour has changed.

12 years, 48 weeks, 1 day ago 18749 No Perforce job exists for this issue. 0 164472 0|i0sihj:
Commons Collections COLLECTIONS-316

LRUMap constructor javadoc and behavior are inconsistent (maxSize cannot be less than 0)

Bug Closed Minor Fixed Unassigned ori ori 10/Feb/09 21:55   09/Nov/14 14:31 28/Feb/13 20:04 3.1 4.0-alpha1, 4.0 Map   0 0 60 60 0% n/a The LRUMap constructor specifies "@param maxSize the maximum size of the map, -1 for no limit"

The first line is then:

if (maxSize < 1) {
throw new IllegalArgumentException("LRUMap max size must be greater than 0");
}

There is nothing wrong with allowing a negative maxSize. This way the map can be used to order elements relative to access time. I think the above code should be remove and the javadoc should stay the same.
0% 0% 60 60 10 years, 44 weeks, 6 days ago 18685 No Perforce job exists for this issue. 0 164421 0|i0si67:
Commons Collections COLLECTIONS-111

IteratorChain skips over elements in iterator

Bug Closed Major Cannot Reproduce Unassigned Jonathan Giles Jonathan Giles 21/Jan/06 10:12   28/Feb/13 19:52 19/Mar/08 06:52 3.1   Iterator   0 0   Operating System: Windows XP
Platform: PC
Hi there,
When using the IteratorChain class to add multiple iterators, it appears that
using itChain.hasNext() and itChain.next() skips a number of elements in the
iterator at each step.

Given a single iterator of 7 elements, and using the following code:

private IteratorChain buildIterator() {
// this iterator contains the children of the current object only
Iterator it = getChildren(p);

// we use an IteratorChain to add multiple iterators together without the
overhead of copying
IteratorChain itChain = new IteratorChain(it);

return itChain;
}

and then simply
IteratorChain it = treeModel.getAllTreeNodes(obj);

// FIXME this only prints one or two of the results, which is a bug!
while (it.hasNext())
System.out.println(": " + it.next().getClass());

I put in 7 elements, but only get 2 out - the 2nd and the last elements. It
appears that through my debugging that the nextClause variable is updated even
when the hasNext() function is called.

Also, if I put 7 system.out.println statements, all elements are printed as normal.
12 years, 1 week, 6 days ago 18887 No Perforce job exists for this issue. 0 38341 164597 0|i0sj9b:
Commons Collections COLLECTIONS-69

[collections] Comparable on AbstractKeyValue

Bug Closed Major Won't Fix Unassigned Shishir Shishir 03/Jan/05 01:54   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: All
Platform: All
Can either the AbstractKeyValue or DefaultKeyValue implement Comparable. Many a
times, the KeyValue needs to be sorted on key,value and don't want to have
screate a new Comparator in order to sort it
15 years, 13 weeks ago 18929 No Perforce job exists for this issue. 0 32914 164639 0|i0sjin:
Commons Collections COLLECTIONS-30

[collections] TransformedMap.putAll fails with empty Map

Bug Closed Major Duplicate Unassigned Paul Libbrecht Paul Libbrecht 09/Feb/06 22:45   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
Using collections 3.1, TransformedMap.putAll creates a new LinkedMap with the
size of the parameter's collection as capacity. When this size is zero, however,
this raises exceptions.

paul
14 years, 7 weeks, 5 days ago 18968 No Perforce job exists for this issue. 0 38591 164678 0|i0sjrb:
Commons Collections COLLECTIONS-72

[collections] java.lang.ArrayIndexOutOfBoundsException

Bug Closed Major Duplicate Unassigned Stijn Christiaens Stijn Christiaens 08/Feb/06 20:03   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: other
Platform: Other
In BoundedFifoBuffer (line 340):

// Other elements require us to shift the subsequent elements

int i = lastReturnedIndex + 1;

while (i != end) {

if (i >= maxElements) {

elements[i - 1] = elements[0];

i = 0;

} else {

elements[i - 1] = elements[i];

i++;

}

}
An AIOOBException is thrown at line 347 when trying to remove an element and i = 0.
14 years, 7 weeks, 6 days ago 18926 No Perforce job exists for this issue. 0 38565 164636 0|i0sjhz:
Commons Collections COLLECTIONS-113

[collections] ExtendedProperties#convertProperties doesn't inherit defaults.

Bug Closed Major Fixed Unassigned Shinobu Kawai Shinobu Kawai 13/Nov/04 00:44   02/May/13 02:28 15/Mar/08 21:36 3.1       0 0   Operating System: other
Platform: Other
ExtendedProperties#convertProperties() uses props.keys() instead of
props.propertyNames(), causing the defaults properties to be discarded.
14 years, 45 weeks, 1 day ago 18885 No Perforce job exists for this issue. 2 32204 164595 0|i0sj8v:
Commons Collections COLLECTIONS-18

[collections] ListOrderedSet broken or documentation wrong.

Bug Closed Minor Fixed Unassigned Rohan Lenard Rohan Lenard 05/Nov/04 08:45   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: All
The method ListOrderedSet.decorate(List list) "decorates" the list, implying
that it leaves the underlying list un-modified. But this is just not true - it
requires a modifiable List so it can remove duplicates. It should at least
warn about this - so you don't have to look in the code to see how it works and
see why it fails when using an unmodifiable list (such as given by
java.util.Collections.unmodifiableList()).

Actually it'd be good to have a variant that worked with unmodifiable lists.
15 years, 13 weeks ago 18980 No Perforce job exists for this issue. 0 32073 164690 0|i0sjtz:
Commons Collections COLLECTIONS-61

[collections] FilterIterator doesn't reset when properties are set

Bug Closed Major Fixed Unassigned Huw Roberts Huw Roberts 30/Dec/05 05:14   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
Test case follows:

[pre]
/**
* Test that when the iterator is changed, the hasNext method
* returns the correct response for the new iterator.
*/
public void testSetIterator() {
Iterator iter1 = Collections.singleton(new Object()).iterator();
Iterator iter2 = Collections.EMPTY_LIST.iterator();

FilterIterator filterIterator = new FilterIterator(iter1);
filterIterator.setPredicate(TruePredicate.getInstance());

assertTrue("filterIterator should have an element",
filterIterator.hasNext());

filterIterator.setIterator(iter2);

assertTrue("filterIterator should not have an element", !
filterIterator.hasNext());
}

/**
* Test that when the predicate is changed, the hasNext method
* returns the correct response for the new predicate.
*/
public void testSetPredicate() {
Iterator iter = Collections.singleton(null).iterator();

FilterIterator filterIterator = new FilterIterator(iter);
filterIterator.setPredicate(TruePredicate.getInstance());

assertTrue("filterIterator should have an element",
filterIterator.hasNext());

filterIterator.setPredicate(NotNullPredicate.getInstance());

assertTrue("filterIterator should not have an element", !
filterIterator.hasNext());
}
[/pre]
14 years, 12 weeks, 3 days ago 18937 No Perforce job exists for this issue. 0 38074 164647 0|i0sjkf:
Commons Collections COLLECTIONS-38

[collections] Javadoc entry page overview has bad links for 'Transformer' and 'Factory'

Bug Closed Trivial Fixed Unassigned andreas przygienda andreas przygienda 02/Jun/05 22:04   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: All
Platform: All
the overview in the entry page of the collections API javadoc has bad links in
the description of the "org.apache.commons.collections.functors" package.
(*...* means an underlying link):

"This package contains implementations of the *Closure*, *Predicate*,
*Transformer* and *Factory* interfaces."

*Transformer* and *Factory* link to the Predicate Interface
14 years, 43 weeks ago 18960 No Perforce job exists for this issue. 0 35186 164670 0|i0sjpj:
Commons Collections COLLECTIONS-33

[collections] AbstractHashedMap: initial threshold too conservative

Bug Closed Major Fixed Unassigned Christian Siefkes Christian Siefkes 23/May/05 00:28   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: All
The (int initialCapacity, float loadFactor) constructor of
org.apache.commons.collections.map.AbstractHashedMap calculates the initial
resize too threshold conservatively, based on the requested initial capacity
instead of the actually chosen initial capacity (which is round up to the next
power of too). This could be fixed switching two lines to calculating the
initial threshold after rounding up the capacity instead of before:

--- AbstractHashedMap.java 2005-05-22 17:04:23.000000000 +0200
+++ AbstractHashedMap-patched.java 2005-05-22 17:08:46.000000000 +0200
@@ -147,4 +147,4 @@
this.loadFactor = loadFactor;
- this.threshold = calculateThreshold(initialCapacity, loadFactor);
initialCapacity = calculateNewCapacity(initialCapacity);
+ this.threshold = calculateThreshold(initialCapacity, loadFactor);
this.data = new HashEntry[initialCapacity];

A map with an requested capacity of 600 and a load factor of 0.75, will start
with an initial array of length 1024. Without the fix, the array will be resized
for the first time as soon as there are 450 entries, i.e. the array is less than
45% filled instead of the 75% suggested by the load factor.
14 years, 45 weeks, 2 days ago 18965 No Perforce job exists for this issue. 0 35012 164675 0|i0sjqn:
Commons Collections COLLECTIONS-70

[collections] TreeList Collections.binarySearch problem - general remove() after previous() problem

Bug Closed Major Fixed Unassigned Tomas D. Tomas D. 08/Jun/05 06:21   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: Windows XP
Platform: Other
Sometimes TreeList crashes if i tried to call:
Collections.binarySearch(queue, n, comp);
with ArrayList is everything ok.

Exception in thread "main" java.lang.NullPointerException
at
org.apache.commons.collections.list.TreeList$TreeListIterator.previous
(TreeList.java:841)
at java.util.Collections.get(Unknown Source)
at java.util.Collections.iteratorBinarySearch(Unknown Source)
at java.util.Collections.binarySearch(Unknown Source)
at utils.queue.QueueSorted.put(QueueSorted.java:51)
at framework.search.GraphSearch.solve(GraphSearch.java:53)
at search.informed.BestFirstSearch.solve(BestFirstSearch.java:20)
at Hlavni.main(Hlavni.java:66)
14 years, 10 weeks, 3 days ago 18928 No Perforce job exists for this issue. 3 35258 164638 0|i0sjif:
Commons Collections COLLECTIONS-12

ListOrderedSet add results in separate objects in set/list if equal

Bug Closed Major Cannot Reproduce Stephen Colebourne Gene Hart Gene Hart 03/Nov/05 07:59   19/Jul/06 22:01 19/Jul/06 22:01 3.1   Set   0 0   Operating System: other
Platform: Other
If you add an object to ListOrderedSet, and then try to replace the object with
add and the objects are different but equals() is true, you will have two
different objects in the internal list and set so after you do an add, doing a
listorderedset.get(i) will return the old object.
13 years, 36 weeks, 6 days ago 18986 No Perforce job exists for this issue. 0 37338 164696 0|i0sjvb:
Commons Collections COLLECTIONS-93

[collections] When the AbstractHashedMap is serialized and deserialized the data array doubles its size

Bug Closed Major Fixed Unassigned Marcos Cesar de Oliveira Marcos Cesar de Oliveira 02/Apr/05 03:19   15/Mar/08 21:36 14/Jul/06 12:04 3.1       1 0   Operating System: Windows XP
Platform: PC
In the method "AbstractHashMap#doReadObject", the method call "threshold =
calculateThreshold(data.length, loadFactor);" is after the "put(key, value);".
The "put" method uses the threshold to check the capacity of the data array.
In this checking, the threshold is zero, leading to a resize of the data array.
At each serialization/deserialization the size of the data array doubles.
13 years, 37 weeks, 4 days ago 18905 No Perforce job exists for this issue. 0 34265 164615 0|i0sjdb:
Commons Collections COLLECTIONS-77

[collections] IteratorChain.remove() in combination with FilterIterator

Bug Closed Major Fixed Unassigned Peter Billen Peter Billen 02/Apr/05 03:52   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: Windows XP
Platform: Other
IteratorChain.remove() throws IllegalStateException when one of the underlying
iterators is a FilterIterator

code:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=64950
14 years, 46 weeks ago 18921 No Perforce job exists for this issue. 2 34267 164631 0|i0sjgv:
Commons Collections COLLECTIONS-49

[collections] Compile Errors when Importing in VAJ 4

Bug Closed Major Won't Fix Unassigned David Müller David Müller 08/Apr/05 18:48   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Windows 2000
Platform: PC
Hi,
when I try to import Collections Framework into IBM VisualAge for Java (VAJ) 4,
I get loads of Compile Errors.
(For your information: VAJ is Java 1.2.2 based...)

Most Errors are in the Testing Framework, so could be ignored.
However, there are quite a few Errors from using

Entry

instead of

Map.Entry,

for Example in

AbstractReferenceMap
public Object get(Object key) {
purgeBeforeRead();
Entry entry = getEntry(key);
if (entry == null) {
return null;
}
return entry.getValue();
}

It would be nice for less adventurous users not to have to change the source
code in order to use this in VAJ.

I can send you the changed sources.

Yours,
David

P.S.: The severity "major" is debatable... 8-)
14 years, 45 weeks, 1 day ago 18949 No Perforce job exists for this issue. 0 34368 164659 0|i0sjn3:
Commons Collections COLLECTIONS-88

[collection] Map filter with MapUtils.predicatedMap feature request

Bug Closed Major Won't Fix Unassigned Luc Carpentier Luc Carpentier 14/Apr/05 15:32   03/May/11 00:36 15/Mar/08 21:36 3.1       0 0   Operating System: other
Platform: Other
Hello,

I stumbled into the following problem:

A client submits an http request with prefixed parameters. Each prefix will
have it's own javabean to populate. So if there are two prefixes, then there
will be two different javabeans to populate from the request parameters.

I created a PrefixPredicate that only allows values with a specific prefix. I
then used this PrefixPredicate to copy the Map with the request parameters to
a predicated Map with:

Map predicatedMap = MapUtils.predicatedMap(dataMap,keyPredicate,null);

However, since the request parameters contain parameters with other prefixes
as well, this returns an IllegalArgumentException.

It would be nice to be able to specify to the MapUtils.predicatedMap method to
ignore entries that do not comply to the predicate instead of to throw an
exception.

There are lots of possabilities to filter on a Collection, but a Map is not a
collection...
8 years, 47 weeks, 1 day ago 18910 No Perforce job exists for this issue. 0 34446 164620 0|i0sjef:
Commons Collections COLLECTIONS-3

NPE: map.LRUMap.reuseMapping(LRUMap.java:272)

Bug Closed Major Cannot Reproduce Unassigned Otis Gospodnetic Otis Gospodnetic 08/Dec/04 03:39   28/Feb/13 19:53 17/Jun/09 09:48 3.1   Map   2 0   Operating System: Linux
Platform: PC
I'm using Collections 3.1 and just found this NPE in my logs:

java.lang.NullPointerException
at
org.apache.commons.collections.map.LRUMap.reuseMapping(LRUMap.java:272)
at
org.apache.commons.collections.map.LRUMap.addMapping(LRUMap.java:243)
at
org.apache.commons.collections.map.AbstractHashedMap.put(AbstractHashedMap.java:282)

I instantiated LRUMap like this:

LRUMap map = new LRUMap(31);

And from there on, I use it like I'd use any Map, putting things into
it, and so on. Maybe I'm not using LRUMap correctly? My _guess_ is
that this occurs when the Map is full, but I am not certain.

I am wrapping the LRUMap in my own Maps as follows, but I think they're
not the culprit:

LRUMap map = new LRUMap(31);
_userSessions = new ExpiringMap(map,
new TimerTTLReferenceHolder(1800000), // ttl=30min
300000); // purge frequency=5min


The only similar thing I found is COM-1288, but it looks like that was fixed
before 3.1 release.

I understand the value of a self-contained unit test that demonstrates this bug,
but it happens only occassionally on my production system, never during
development, so I can't really come up with it :(

My guess is that this is a boundary case, as line 272 is:

loop = loop.next;

So 'loop' is most likely null, and it's null because ... not sure, maybe that
hashIndex is wrong.
10 years, 40 weeks, 6 days ago 18995 No Perforce job exists for this issue. 3 32573 164705 0|i0sjxb:
Commons Collections COLLECTIONS-123

[collections] StaticBucketMap#containsKey(final Object key) can return illegal value.

Bug Closed Major Fixed Unassigned Kazuya Ujihara Kazuya Ujihara 20/Nov/05 18:18   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: Windows XP
Platform: All
org.apache.commons.collections.map.StaticBucketMap#containsKey("any string")
can return true by mistake when null key is containing in buckets.
I think containsKey(Object) method has to be modified like the following.

public boolean containsKey(final Object key) {
int hash = getHash(key);

synchronized (locks[hash]) {
Node n = buckets[hash];

while (n != null) {
- if (n.key == null || (n.key != null && n.key.equals(key))) {
+ if ((n.key == null && key == null) || (n.key != null &&
n.key.equals(key))) {
return true;
}

n = n.next;
}
}
return false;
}

Kazuya Ujihara
14 years, 18 weeks, 6 days ago 18875 No Perforce job exists for this issue. 0 37567 164585 0|i0sj6n:
Commons Collections COLLECTIONS-134

[collections] Error in deserialization of full BoundedFifoBuffer

Bug Closed Major Duplicate Unassigned Tilmann Kuhn Tilmann Kuhn 17/Nov/05 07:52   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: All
Platform: All
If a BoundedFifoBuffer is serialized and then deserialized the value of the end
attribute is set to the max size of the Buffer which is a fault and causes an
ArrayIndexOutOfBoundException during add(object). In this case the value of end
must be set to 0 in the deserialization.
14 years, 19 weeks ago 18864 No Perforce job exists for this issue. 0 37539 164574 0|i0sj47:
Commons Collections COLLECTIONS-11

[Collections] LazyList throws IndexOutOfBoundsException when trying to set a value out of list bounds

Bug Closed Major Cannot Reproduce Unassigned Heston Fernandes Heston Fernandes 11/Nov/05 01:05   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Windows XP
Platform: PC
This was discovered when using struts 1.2.7 with dynamic forms (Tomcat 5.0.24,
jdk 1.4.2). The reset() method in the ActionForm used LazyList.decorate().

if(rooms==null) {
rooms = new ArrayList();
roomPrefs.add("-");
roomPrefs = LazyList.decorate(roomPrefs, factory);
}


However after reset() I get the error below when it tries to initialize the
ArrayList.

IndexOutOfBoundsException -> Index: 1, Size: 1
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.set(ArrayList.java:340)
at
org.apache.commons.collections.list.AbstractListDecorator.set(AbstractListDecorator.java:97)
at
org.apache.commons.beanutils.PropertyUtilsBean.setIndexedProperty(PropertyUtilsBean.java:1417)
at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1016)
at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:811)
at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:298)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:805)
at ....


Possible Solution: For now I've created a class similar to LazyList and have
overridden the set(object, element) method and it has worked.

public Object set(int index, Object element) {
int size = list.size();

// Grow the list
if (index >= size) {
for (int i = size; i <= index; i++) {
list.add(null);
}
}
return list.set(index, element);
}

I'm not sure if I'm using LazyList the right way but thought I'd bring it to
your attention.

Thanks!
14 years, 20 weeks, 4 days ago 18987 No Perforce job exists for this issue. 0 37450 164697 0|i0sjvj:
Commons Collections COLLECTIONS-101

[collections] CursorableLinkedList iteration broken with previous

Bug Closed Major Fixed Unassigned Stephen Colebourne Stephen Colebourne 16/Jul/05 23:14   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: All
Platform: All
With a CursorableLinkedList, if you perform a Next, Next, Previous on an
iterator/cursor, then remove the last object returned by index from the list,
you will leave the cursor in an invalid state.

You should at this point not be able to call remove/set on the iterator, but you
can.
14 years, 37 weeks, 3 days ago 18897 No Perforce job exists for this issue. 0 35766 164607 0|i0sjbj:
Commons Collections COLLECTIONS-42

[collections] PriorityBuffer iterator does not remove elements properly

Bug Closed Major Cannot Reproduce Unassigned Dusan Chromy Dusan Chromy 02/Mar/05 01:11   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: All
Platform: All
The following code snippet:

System.out.println("----------");
PriorityBuffer s = new PriorityBuffer();
s.add(new Integer(1));
s.add(new Integer(2));
s.add(new Integer(3));

for (Iterator it = s.iterator(); it.hasNext(); s.remove() )
System.out.println(it.next());
System.out.println("----------");

Prints this:
----------
1
3
----------
Element 2 is lost, contrary to javadoc of java.util.Iterator
15 years, 1 week, 6 days ago 18956 No Perforce job exists for this issue. 0 33791 164666 0|i0sjon:
Commons Collections COLLECTIONS-75

[collections] PriorityBuffer ignores natural order of elements

Bug Closed Blocker Incomplete Unassigned Dusan Chromy Dusan Chromy 01/Mar/05 23:52   16/May/06 12:16 16/May/06 12:16 3.1       0 0   Operating System: All
Platform: All
The following code snippet:
-------------------------------
PriorityBuffer r = new PriorityBuffer();
r.add(new Integer(2));
r.add(new Integer(1));
r.add(new Integer(0));
for (Iterator it = r.iterator(); it.hasNext(); )
System.out.println(":"+it.next());
-------------------------------
Prints this
:0
:2
:1
15 years, 5 weeks ago 18923 No Perforce job exists for this issue. 0 33788 164633 0|i0sjhb:
Commons Collections COLLECTIONS-124

[collections][PATCH] SetUniqueList breaks when swapping entries

Bug Closed Major Fixed Unassigned Tom Dunham Tom Dunham 29/Jan/05 04:15   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: All
Platform: PC
If you create a SetUniqueList with two entries a and b:
[a,b]
Then you do:
Object a = l.get(0);
l.set(0, b)
l.add(0, a);
You expect to have swapped the two entries. But you get
[b]
Which seems to be wrong.
15 years, 8 weeks, 4 days ago 18874 No Perforce job exists for this issue. 3 33294 164584 0|i0sj6f:
Commons Collections COLLECTIONS-36

[collections] MultiHashMap.remove(key, value) always returns a value

Bug Closed Major Fixed Unassigned Tad Marko Tad Marko 24/Nov/04 06:01   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Linux
Platform: PC
According to the documentation, MultiHashMap.remove(key, value) will only return
a value when it removes a value, null if nothing was removed. Instead, it always
returns a value.
15 years, 13 weeks ago 18962 No Perforce job exists for this issue. 0 32366 164672 0|i0sjpz:
Commons Collections COLLECTIONS-53

[collections] Iterator.remove() in UnboundedFifoBuffer does not work

Bug Closed Major Fixed Unassigned Andreas Schlosser Andreas Schlosser 14/Jul/05 18:29   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: All
Platform: All
The implementation of Iterator.remove() in the unbounded fifo buffer is buggy.
It produces an ArrayIndexOutOfBoundExceptions when it needs to swap around the
end of the array to its start.

The code should be:

public void remove() {
if (lastReturnedIndex == -1) {
throw new IllegalStateException();
}

// First element can be removed quickly
if (lastReturnedIndex == head) {
UnboundedFifoBuffer.this.remove();
lastReturnedIndex = -1;
return;
}

// Other elements require us to shift the subsequent elements
/*
* This loop is buggy in the original implementation!
*/
int i = lastReturnedIndex + 1;
while (i != tail) {
buffer[decrement(i)] = buffer[i];
i = increment(i);
}

lastReturnedIndex = -1;
tail = decrement(tail);
buffer[tail] = null;
index = decrement(index);
}

while the original buggy loop is:

// Other elements require us to shift the subsequent elements
int i = lastReturnedIndex + 1;
while (i != tail) {
if (i >= buffer.length) {
buffer[i - 1] = buffer[0];
i = 0;
} else {
buffer[i - 1] = buffer[i];
i++;
}
}
14 years, 37 weeks, 3 days ago 18945 No Perforce job exists for this issue. 0 35733 164655 0|i0sjm7:
Commons Collections COLLECTIONS-14

[collections] Missing putAll(Map map) in MultiHashMap since 3.1

Bug Closed Major Fixed Unassigned Sven Macke Sven Macke 06/Jul/05 23:44   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Windows 2000
Platform: PC
I just upgraded to version 3.1 and noticed some errors in my application. The
cause is the method putAll(Map map) I used to call on a MultiHashMap to copy to
content of one to another. That method is not defined in MultiHashMap any more,
so HashMap.putAll(Map map) is used. The result of that is a MultiHashMap that
contains ONE value per key and the value itself is a Collection.

Here is some test code I would expect to work, but it fails:

public class MultiHashMapTest extends TestCase
{
public void testIt()
{
MultiMap original = new MultiHashMap();
original.put("key", "object1");
original.put("key", "object2");

MultiMap copy = new MultiHashMap();
copy.putAll(original);

assertEquals(original.values().size(), copy.values().size());
assertTrue(copy.containsValue("object1"));
assertTrue(copy.containsValue("object2"));
}
}
14 years, 37 weeks, 2 days ago 18984 No Perforce job exists for this issue. 0 35631 164694 0|i0sjuv:
Commons Collections COLLECTIONS-64

[collections] UnboundedFifoBuffer deserialization is broken

Bug Closed Major Fixed Unassigned Stephen Colebourne Stephen Colebourne 16/Jul/05 20:24   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: All
Platform: All
The patch should be:

private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
int size = in.readInt();
- buffer = new Object[size];
+ buffer = new Object[size + 1];
for (int i = 0; i < size; i++) {
buffer[i] = in.readObject();
}
head = 0;
tail = size;
}

Setting tail = size - 1; just caused another bug (ie you couldn't get the last
element in the buffer). This is because tail is supposed to point to the next
unused cell in the buffer array. By creating the buffer to be size + 1, tail
will be set to a valid cell within buffer that is empty (but the cell before it
has an element in it), and the class works properly.

Thomas Knych, Jordan Krey & Citigroup Analytics Dev team
14 years, 37 weeks, 3 days ago 18934 No Perforce job exists for this issue. 0 35763 164644 0|i0sjjr:
Commons Collections COLLECTIONS-107

[collections] AbstractMapBag.BagIterator.remove broken

Bug Closed Major Fixed Unassigned Stephen Colebourne Stephen Colebourne 15/Jul/05 08:07   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: All
Platform: All
I can't get in to CVS to see if this is fixed, but there is a bug in
AbstractMapBag in 3.1: BagIterator.remove() does not properly remove the
last instance of a given item; the result is infinite looping. Here is a
patch.

-steve

Steve Clark
ECOS Development Group
steve_clark@fws.gov
(970)226-9291


--- AbstractMapBag.java.orig 2005-07-14 11:14:33.708373173 -0600
+++ AbstractMapBag.java 2005-07-14 11:15:30.566623793 -0600
@@ -221,7 +221,7 @@
throw new IllegalStateException();
}
MutableInteger mut = (MutableInteger) current.getValue();
- if (mut.value > 0) {
+ if (mut.value > 1) {
mut.value--;
parent.size--;
} else {
14 years, 37 weeks, 4 days ago 18891 No Perforce job exists for this issue. 0 35747 164601 0|i0sja7:
Commons Collections COLLECTIONS-104

[collections] Only last element is removeable when CircularFifoBuffer is full

Bug Closed Major Fixed Unassigned Amir Tahvildaran Amir Tahvildaran 13/Jan/05 03:30   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: Linux
Platform: PC
If the circular fifo buffer is full and you remove an item, that is not the last
one, it breaks.

code example:

import java.io.*;
import org.apache.commons.collections.buffer.*;

class Stub {
public static void main(String[] args) {
CircularFifoBuffer fifo = new CircularFifoBuffer(5);
System.out.println(fifo);

fifo.add(new String("1"));
System.out.println(fifo);

fifo.add(new String("2"));
System.out.println(fifo);

fifo.add(new String("3"));
System.out.println(fifo);

fifo.add(new String("4"));
System.out.println(fifo);

System.out.println("adding 5");
fifo.add(new String("5"));
System.out.println(fifo);

String six = new String("6");
System.out.println("adding 6");
fifo.add(six);
System.out.println(fifo);

/* uncomment the following block to avoid problem
System.out.println("fifo.isFull?:"+fifo.isFull());
System.out.println("removing 6");
fifo.remove(new String("6"));
System.out.println(fifo);
*/

System.out.println("fifo.isFull?:"+fifo.isFull());

System.out.println("removing 3");
fifo.remove(new String("3"));
System.out.println(fifo);

System.out.println("removing 4");
fifo.remove(new String("4"));
System.out.println(fifo);

System.out.println("clearing");
fifo.clear();
System.out.println("removing 4");
fifo.remove(new String("4"));
System.out.println(fifo);

}
}



==============

output busted:

[]
[1]
[1, 2]
[1, 2, 3]
[1, 2, 3, 4]
adding 5
[1, 2, 3, 4, 5]
adding 6
[2, 3, 4, 5, 6]
fifo.isFull?:true
removing 3
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.commons.collections.buffer.BoundedFifoBuffer$1.remove(BoundedFifoBuffer.java:347)
at java.util.AbstractCollection.remove(AbstractCollection.java:255)
at Stub.main(Stub.java:40)
14 years, 7 weeks, 6 days ago 18894 No Perforce job exists for this issue. 0 33071 164604 0|i0sjav:
Commons Collections COLLECTIONS-85

ReferenceMap clears bindings too early

Bug Closed Major Invalid Unassigned Eric Bodden Eric Bodden 04/Mar/06 15:58   07/Aug/06 21:08 07/Aug/06 21:08 3.1   Map   0 0   Operating System: Windows XP
Platform: Other
Hello. This week I had to debug some small example program we are currently
working on and it really took me a long time to find the actual problem because
apprently there seems to be a bug in the implementation of ReferenceMap, which
was really very unexpected for me. To me this seems very critical because I
reckon that the ReferenceMap is in wide use. Hence I am describing my findings
in detail.

The code is AspectJ code, but I also provide the bytecode. The puspose of the
code is to detect the so-called "lock order reversal pattern", a temporal event
pattern which gives indication of potentially unsafe locking. It tries to
detect patterns where a thread t1 tries to acquire locks in the order l1 l2 and
another thread t2 tries to do so in the order r2 r1.

When you compile the attached code with the AspectBench compiler (www.
aspectbench.org) and then execute "java LORTest", depending on the map
implementation you choose, one of the following traces is produced:

- "log": your commons impl. (Reference identity map with weak key and values)
- "log_jre": the JRE impl. (hash map with weak keys, no identity map, but does
not matter since the keys are threads, which do not implement equals(...))

(Both logs are also in the tarball.)

In log_jre you see that the LOR is detected (at the bottom). That works as
follows: Whenever a lock is taken, the relationship (thread,lock) is put into a
first (weak) map (see logging points "Xa"). Also, for all such relations which
are contained already, we put a reference to a pair (thread,(lock1,lock2)) into
a second map (logging points "Xb"). This represents the information "thread"
took first "lock1" then "lock2".

As "log" shows, the weak map by commons is looses all the sudden some bindings.
(Compare to log_jre.) This seems really buggy, since subsequent logging output
shows that the threads and locked resources still exist!

For me this is fully deterministically reproducable. I am using Windows XP with
this JRE:

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

You can compile the code (using the AspectBench compiler) with "compile.bat" or
you can just run it with "run.bat", if you like.
13 years, 34 weeks, 2 days ago 18913 No Perforce job exists for this issue. 1 38853 164623 0|i0sjf3:
Commons Collections COLLECTIONS-51

[collections] LRUMap loses values when resizing.

Bug Closed Critical Incomplete Unassigned Dave Dandeneau Dave Dandeneau 23/Feb/06 01:15   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Windows XP
Platform: PC
I am using the LRUMap and I have noticed that when it resizes the Map it loses
the values that were in it previously. I noticed this when it was resizing my
map from size of 2 to size of 4.
14 years, 5 weeks, 6 days ago 18947 No Perforce job exists for this issue. 0 38753 164657 0|i0sjmn:
Commons Collections COLLECTIONS-67

[collections] PriorityBuffer does not implement Serializable

Bug Closed Minor Fixed Unassigned Steve Phelps Steve Phelps 12/Aug/05 23:42   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
The class org.apache.commons.collections.buffer.PriorityBuffer does not
implement java.io.Serializable
14 years, 25 weeks, 3 days ago 18931 No Perforce job exists for this issue. 2 36163 164641 0|i0sjj3:
Commons Collections COLLECTIONS-48

[collections] TransformedMap putAll(empty map) causes IllegalArgumentException

Bug Closed Major Fixed Unassigned Marc Lottman Marc Lottman 30/Apr/05 06:33   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Windows XP
Platform: PC
If you create a TransformedMap, and then call map.putAll with an empty map as
an argument, an IllegalArgumentException is thrown. putAll should be able to
handle empty maps without erroring. The error occurs regardless of whether
the decorated map has any contents. The implementation of the Transformers
attached does not matter. I am using Java 1.4.2_07.

Example code:
Map map = TransformedMap.decorate(
new HashMap(),
TransformerUtils.nopTransformer(),
TransformerUtils.nopTransformer());

map.putAll(new HashMap()); // This causes IllegalArgumentException!

Fails with the following error:

java.lang.IllegalArgumentException: Initial capacity must be greater than 0
at org.apache.commons.collections.map.AbstractHashedMap.<init>
(AbstractHashedMap.java:142)
at org.apache.commons.collections.map.AbstractHashedMap.<init>
(AbstractHashedMap.java:127)
at org.apache.commons.collections.map.AbstractLinkedMap.<init>
(AbstractLinkedMap.java:95)
at org.apache.commons.collections.map.LinkedMap.<init>
(LinkedMap.java:78)
at org.apache.commons.collections.map.TransformedMap.transformMap
(TransformedMap.java:153)
at org.apache.commons.collections.map.TransformedMap.putAll
(TransformedMap.java:190)
at net.carefx.contextagent.plugin.ldapuser.PluginTest.main
(PluginTest.java:71)
14 years, 7 weeks, 5 days ago 18950 No Perforce job exists for this issue. 0 34686 164660 0|i0sjnb:
Commons Collections COLLECTIONS-122

[collections] CircularFifoBuffer not really Serializable

Bug Closed Major Fixed Unassigned Kalle Gustafsson Kalle Gustafsson 27/Sep/04 14:24   15/Mar/08 21:36 15/Mar/08 21:36 3.1 3.2     0 0   Operating System: Solaris
Platform: Sun
Create a CircularFifoBuffer of size N. Serialize and deserialize a couple of
times. When adding element N+1, an error occurs. (OutOfMemoryError in our
testing environment, ArrayIndexOutOfBounds when running the code snippet.)

The error can be reproduced by running the following code snippet in a scrapbook
page in WebSphere Studio 5.1.2 (default JRE) on Windows XP (The error occurs at
the third add operation):

org.apache.commons.collections.buffer.CircularFifoBuffer b = new
org.apache.commons.collections.buffer.CircularFifoBuffer(2);

b.add("a");

java.io.ByteArrayOutputStream bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b);

org.apache.commons.collections.buffer.CircularFifoBuffer b2 =
(org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();

b2.add("b");

bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b2);

b = (org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();

b.add("c");

bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b);

b2 = (org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();
14 years, 19 weeks ago 18876 No Perforce job exists for this issue. 0 31433 164586 0|i0sj6v:
Commons Collections COLLECTIONS-59

[collections] FastArrayList iterator method throwing ConcurrentModificationException in 'fast' mode

Bug Closed Major Fixed Unassigned Robert Cooke Robert Cooke 17/Jun/04 06:55   15/Mar/08 21:35 15/Mar/08 21:35 3.1 3.2     0 0   Operating System: Linux
Platform: All
Please review the below code, I was under the impression that this not throw an
exception.



Thanks,

Rob Cooke.



----------------------------





import org.apache.commons.collections.FastArrayList;

import java.util.Iterator;



public class Test2 extends Thread{

public static void main(String argv[]) throws Exception{

FastArrayList array=new FastArrayList();

array.add("this");

array.add("is");

array.add("a");

new Test2(array).start();

array.setFast(true);

Thread.sleep(2000);

array.add("test");

}

protected FastArrayList array;

public Test2(FastArrayList array){

this.array=array;

}

public void run(){

for(Iterator i=array.iterator();i.hasNext();){

try{Thread.sleep(1000);}catch(Exception e){}

System.out.println(i.next());

}

}

}
15 years, 40 weeks, 5 days ago 18939 No Perforce job exists for this issue. 0 29625 164649 0|i0sjkv:
Commons Collections COLLECTIONS-84

TreeList with inproved iterator() and listIterator() implementation

Bug Closed Major Fixed Unassigned Joerg Schmuecker Joerg Schmuecker 12/May/04 23:08   15/Mar/08 21:36 15/Mar/08 21:36 3.1       0 0   Operating System: other
Platform: Other
Added references to next and and prev using a flag. This is called Faedelung in
German :-)
15 years, 46 weeks, 5 days ago 18914 No Perforce job exists for this issue. 2 28930 164624 0|i0sjfb:
Commons Collections COLLECTIONS-65

[collections] Collection inside Abstract[AnyCollection]Decorator really needed to be transient?

Bug Closed Major Cannot Reproduce Unassigned Xavier Dury Xavier Dury 07/Sep/04 21:42   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
Hi,

I would like to know if there was any good reason for all abstract decorator
classes (like AbstractMapDecorator) to have their decorated collection (map)
transient? It doesn't help when trying to store decorated collections with
XStream for example... Maybe there's a -really- good reason but I can't see it.

thanks a lot and go on with the good work! :)

Xavier.
15 years, 29 weeks, 6 days ago 18933 No Perforce job exists for this issue. 0 31091 164643 0|i0sjjj:
Commons Collections COLLECTIONS-26

CompositeSet always supports remove operation

Bug Closed Major Fixed Unassigned Koji Sekiguchi Koji Sekiguchi 07/Sep/04 13:38   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
CompositeSet javadoc says "If no strategy is provided then add and remove are
unsupported." but the class always supports remove operation. The documentation
should be revised as "If no strategy is provided then add is unsupported."

regards,

Koji
15 years, 27 weeks, 5 days ago 18972 No Perforce job exists for this issue. 0 31082 164682 0|i0sjs7:
Commons Collections COLLECTIONS-37

[collections] The commons-collections 'binary distro' on the Jakarta Website is actually the 'source distro'

Bug Closed Major Won't Fix Unassigned David Tonhofer David Tonhofer 23/Aug/04 23:22   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: Linux
Platform: PC
The subject says it all
15 years, 32 weeks ago 18961 No Perforce job exists for this issue. 0 30806 164671 0|i0sjpr:
Commons Collections COLLECTIONS-39

[collections] ExtendedProperties should not just allow NPEs

Bug Closed Minor Fixed Unassigned john tal john tal 06/Aug/04 01:23   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: Other
Its really an annoyance because I frequently have my debugger stop on
NullPointerException.

ExtendedProperties.readProperty

Change from
String line = readLine().trim();
to
String line = readLine();
if(line != null) line = line.trim(); else return null;

Also in ExtendedProperties.load

while (true) {
String line = reader.readProperty();
if(line == null)
return;
int equalSign = line.indexOf('=');
15 years, 27 weeks, 5 days ago 18959 No Perforce job exists for this issue. 0 30497 164669 0|i0sjpb:
Commons Collections COLLECTIONS-46

[collections] CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c

Bug Closed Major Won't Fix Unassigned Gunnar Zarncke Gunnar Zarncke 30/Jul/04 19:26   15/Mar/08 21:35 15/Mar/08 21:35 3.1       0 0   Operating System: other
Platform: All
CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c
as documented in the API.
The implementation passes this collection to
TransformedCollection.decorate(collection, transformer)
and further to
new TransformedCollection(coll, transformer);
where super(c) simply stored it WITHOUT conversion.
15 years, 34 weeks, 6 days ago 18952 No Perforce job exists for this issue. 1 30408 164662 0|i0sjnr:
Commons Collections COLLECTIONS-587

commons-collections-3.2.2 does not compile under docker fedora21

Bug Resolved Major Won't Fix Unassigned Marc Pawlowsky Marc Pawlowsky 26/Apr/16 16:36 18/Mar/20 02:41 26/Apr/16 21:10 26/Apr/16 21:10 3.2       0 1   docker, fedora21 In a clean environment using docker, compile errors

$cat Dockerfile
FROM fedora:21
RUN yum update -y
RUN yum install -y java-1.8.0-openjdk unzip maven wget
RUN wget http://apache.mirror.rafal.ca//commons/collections/source/commons-collections-3.2.2-src.zip
RUN unzip commons-collections-3.2.2-src.zip
RUN cd commons-collections-3.2.2-src && mvn initialize
RUN cd commons-collections-3.2.2-src && mvn install
RUN chmod -R 755 /root
CMD /bin/bash
$docker build .
<snip/>
Downloaded: http://repo.maven.apache.org/maven2/commons-[INFO] Changes detected - recompiling the module!
[INFO] Compiling 273 source files to /commons-collections-3.2.2-src/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[INFO] 4 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.104 s
[INFO] Finished at: 2016-04-26T12:35:24-04:00
[INFO] Final Memory: 19M/203M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project commons-collections: Compilation failure: Compilation failure:
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
The command '/bin/sh -c cd commons-collections-3.2.2-src && mvn install' returned a non-zero code: 1
3 years, 47 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2wrdr:
Commons Collections COLLECTIONS-359

A ∩ B != B ∩ A when duplicates are present in a list

Bug Closed Major Fixed Unassigned Mark Shead Mark Shead 05/Jul/10 14:58   09/Nov/14 14:31 28/Feb/13 19:37 3.2 4.0-alpha1, 4.0 Collection   0 1   When duplicates are present in a list, ListUtils.intersection doesn't behave as expected. The intersection of two lists should give the same result regardless of which list comes first. ListUtils.intersection(A,B) should equal ListUtils.intersection(B,A). This is not the case when the list contains duplicates.

Right now:
[a, b] ∩ [a, a, b, b] = [a, a, b, b]
and
[a, a, b, b] ∩ [a, b] = [a, b]

Expected behavior:

[a, a, b, b] ∩ [a, b] = [a, b]
[a, b] ∩ [a, a, b, b] = [a, b]


Code demonstrating the problem.

List A = new ArrayList();
List B = new ArrayList();
A.add("a");
A.add("b");
B.add("a");
B.add("a");
B.add("b");
B.add("b");
System.out.println("List A: " + A);
System.out.println("List B: " + B);
System.out.println("A ∩ B = " + ListUtils.intersection(A,B));
System.out.println("B ∩ A = " +ListUtils.intersection(B,A));

output:

List A: [a, b]
List B: [a, a, b, b]
A ∩ B = [a, a, b, b]
B ∩ A = [a, b]
9 years, 36 weeks, 2 days ago 18644 No Perforce job exists for this issue. 1 164388 0|i0shyv:
Commons Collections COLLECTIONS-360

FilterListIterator#hasNext throws exception (associate with JUnit tests)

Bug Closed Major Fixed Jochen Wiedmann Sai Zhang Sai Zhang 23/Aug/10 19:29   09/Nov/14 14:31 01/Mar/11 22:17 3.2 4.0-alpha1, 4.0     0 1   ubuntu Hi,

I found the some of the iterator classes does not fulfill the iterator specification of JDK.

e.g. hasNext() should never throw exception.

Here is an automatically generated junit test (I am now writing a tool)

{code:java}
public void test233() throws Throwable {
java.lang.Integer var6 = new java.lang.Integer(0);
org.apache.commons.collections.list.GrowthList var7 = new org.apache.commons.collections.list.GrowthList(var6);
org.apache.commons.collections.Predicate var9 = org.apache.commons.collections.PredicateUtils.anyPredicate((java.util.Collection)var7);
java.lang.Long var10 = new java.lang.Long(10L);
org.apache.commons.collections.iterators.FilterListIterator var13 = new org.apache.commons.collections.iterators.FilterListIterator(var9);
//this line throws exception!
var13.hasNext();
}
{code}
could you please check it to confirm whether it is bug or I misunderstand the specification of apache common collections?

thanks,
9 years, 4 weeks ago 18643 No Perforce job exists for this issue. 1 164387 0|i0shyn:
Commons Collections COLLECTIONS-357

CollectionUtils.removeAll invokes wrong Listutils method

Bug Closed Critical Duplicate Unassigned Fabian Lange Fabian Lange 24/Jun/10 20:03   09/Nov/14 14:31 28/Feb/13 19:25 3.2 4.0-alpha1, 4.0 Collection   0 0   {code}
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
{code}
9 years, 36 weeks, 2 days ago 18646 No Perforce job exists for this issue. 0 164390 0|i0shzb:
Commons Collections COLLECTIONS-331

CollatingIterator NPE when Comparator is null

Bug Closed Minor Fixed Jochen Wiedmann Michael Krkoska Michael Krkoska 24/Jun/09 14:32   09/Nov/14 14:31 08/Mar/11 22:33 3.2 4.0-alpha1, 4.0 Iterator   0 1 300 300 0% Run the attached Test against commons-collections-3.2.1. While the JavaDoc for CollatingIterator claims

{{@param comp the comparator to use to sort, or null to use natural sort order}}

the test fails, because the comparator is null.

Fixing this requires a change in {{org.apache.commons.collections.iterators.CollatingIterator.least()}}:

{code}
if (comparator.compare(curObject,leastObject) < 0) { ...
{code}

could be replaced with

{code}
int c = comparator==null?((Comparable)curObject).compareTo(leastObject):comparator.compare(curObject,leastObject);
if (c < 0) { ...
{code}


The workaround is to provide a comparator, of course.
0% 0% 300 300 7 years, 34 weeks, 5 days ago 18672 No Perforce job exists for this issue. 2 164410 0|i0si3r:
Commons Collections COLLECTIONS-373

Bug in class#ListOrderedSet with reproducible JUnit test

Bug Closed Major Invalid Unassigned Sai Zhang Sai Zhang 03/Apr/11 07:43 18/Mar/20 02:40 27/Nov/15 21:47 23/Jan/13 17:05 3.2       0 0   jdk 1.6.x Hi all:

I am writing an automated bug finding tool, and using
Apache Commons Collections as an experimental subject
for evaluation.

The tool creates executable JUnit tests as well as
explanatory code comments. I attached one bug-revealing
test as follows. Could you please kindly check it, to
see if it is a real bug or not?

Also, it would be tremendous helpful if you could give
some feedback and suggestion on the generated code comments?
From the perspective of developers who are relatively familiar
with the code,
is the automatically-inferred comment useful in understanding
the generated test? is the comment helpful in bug fixing?

Your suggestion will help us improve the tool.

Please see attachment for the failed test. A little explaination
on the generated code comments in the failed test

//explaination:
//Test passes if var53 is: (java.lang.Boolean)false ===> means:
// test passes if var52 is not added to var28 (only in that case, var53 is false)
boolean var53 = var28.add((java.lang.Object)var52);
patch
7 years, 8 weeks, 6 days ago 18630 No Perforce job exists for this issue. 1 90355 0|i0ftd3:
Commons Collections COLLECTIONS-374

Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test

Bug Closed Major Won't Fix Unassigned Sai Zhang Sai Zhang 03/Apr/11 08:02 18/Mar/20 02:41 27/Nov/15 21:47 18/Apr/13 19:09 3.2       0 0   jdk 1.6.0 Hi all:

(as in the previous post)

I am writing an automated bug finding tool, and using
Apache Commons Collections as an experimental subject
for evaluation.

The tool creates executable JUnit tests as well as
explanatory code comments. I attached one bug-revealing
test as follows. Could you please kindly check it, to
see if it is a real bug or not?

Also, it would be tremendous helpful if you could give
some feedback and suggestion on the generated code comments?
From the perspective of developers who are relatively familiar
with the code,
is the automatically-inferred comment useful in understanding
the generated test? is the comment helpful in bug fixing?

Your suggestion will help us improve the tool.

Please see attachment for the failed test.

The comment appears in the form of:
//Tests pass if .... (it gives some small change to the test which can make the failed test pass)
6 years, 48 weeks, 5 days ago 18629 No Perforce job exists for this issue. 1 90354 0|i0ftcv:
Commons Collections COLLECTIONS-355

class cast exception in common collection-3.2 jar

Bug Closed Major Invalid Unassigned maneesh maneesh 26/May/10 13:18   19/Jun/10 19:37 19/Jun/10 19:37 3.2   Map   0 0   Unix, jdk 1.5.0.06 Recently I have upgraded common collection jar to 3.2 version. After that I got a class cast exception in the following code java code
String checkedInStation = (String)(((HashMap)lstQueuedPsgrs.get(startIndex))
.get("PSGRCHECKEDINSTATION"));

The exception detail as below

java.lang.ClassCastException: org.apache.commons.collections.map.ListOrderedMap
at sun.reflect.GeneratedMethodAccessor279.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation
9 years, 40 weeks, 3 days ago 18648 No Perforce job exists for this issue. 0 164391 0|i0shzj:
Commons Collections COLLECTIONS-371

BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection)

Bug Closed Critical Duplicate Unassigned li gui li gui 31/Jan/11 19:17   01/Feb/11 07:19 01/Feb/11 07:19 3.2   Collection   0 0   line: 1121
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove); //<<<<<-------- here absolutely wrong!

}

9 years, 8 weeks, 1 day ago 18632 No Perforce job exists for this issue. 0 164379 0|i0shwv:
Commons Collections COLLECTIONS-369

CollectionUtils#removeAll is broken

Bug Closed Major Duplicate Unassigned Michael Harris Michael Harris 06/Jan/11 05:52   06/Jan/11 07:29 06/Jan/11 07:29 3.2       0 0   method calls into ListUtils#retainAll instead of ListUtils#removeAll. Should be easy fix for someone with commit rights.
9 years, 11 weeks, 5 days ago 18634 No Perforce job exists for this issue. 0 164380 0|i0shx3:
Commons Collections COLLECTIONS-363

TransformedMap is Serializable but its superclass doesn't define an accessible void constructor

Bug Closed Major Fixed Unassigned Sebb Sebb 16/Oct/10 01:39   09/Nov/14 14:31 20/Dec/10 19:25 3.2 4.0-alpha1, 4.0 Map   0 1   TransformedMap is Serializable but its superclass doesn't define an accessible void constructor.
For example, the following test fails:

{code}
public void testSerialisation() throws Exception {
TransformedMap<String, String, String, String> map = TransformedMap.decorate(
new HashMap<String, String>(), NOPTransformer.<String> getInstance(), NOPTransformer.<String> getInstance());
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bytes);
out.writeObject(map); // fails with java.io.InvalidClassException: org.apache.commons.collections.splitmap.TransformedMap; no valid constructor
out.close();
}
{code}
9 years, 14 weeks, 1 day ago 18640 No Perforce job exists for this issue. 4 164385 0|i0shy7:
Commons Collections COLLECTIONS-377

CollatingIterator throws NullPointerException when constructor is given null (or no) Comparator

Bug Closed Minor Duplicate Unassigned Ryan Hochstetler Ryan Hochstetler 18/Jul/11 19:51 18/Mar/20 02:41 09/Nov/14 14:31 03/Jun/12 11:19 3.2 4.0-alpha1, 4.0 Iterator   0 1   Java 1.6.0_26 CollatingIterator's javadoc (http://commons.apache.org/collections/api-release/index.html) states that natural sort ordering will be used when null is passed as the Comparator argument to any of the constructors accepting one (and for the nullary constructor). The following stack is thrown from the subsequent unit test. The implementation of least() does not appear to account for the natural sort order case.

java.lang.NullPointerException
at org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:334)
at org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230)
at mil.af.statistics.jutl.collection.MutableDataSeriesTest...


@SuppressWarnings("unchecked")
@Test
public void testCollatingIteratorNaturalOrdering() throws Exception
{
Integer[] expected =
{ Integer.valueOf(1), Integer.valueOf(2), Integer.valueOf(3), Integer.valueOf(4), Integer.valueOf(5),
Integer.valueOf(6) };
List<Integer> evens = Arrays.asList(new Integer[]
{ Integer.valueOf(2), Integer.valueOf(4), Integer.valueOf(6) });
List<Integer> odds = Arrays.asList(new Integer[]
{ Integer.valueOf(1), Integer.valueOf(3), Integer.valueOf(5) });

Iterator<Integer> collatingIter = new CollatingIterator(null, evens.iterator(), odds.iterator());

for (Integer expectedInt : expected)
{
assertTrue(collatingIter.hasNext());
assertEquals(expectedInt, collatingIter.next());
}
}

Workaround: provide a Comparator that implements the natural ordering contract.
7 years, 42 weeks, 2 days ago 18626 No Perforce job exists for this issue. 0 164377 0|i0shwf:
Commons Collections COLLECTIONS-304

SetUniqueList set method use corrupts uniqness

Bug Closed Major Fixed Unassigned Rafał Figas Rafał Figas 05/Sep/08 10:43   08/Nov/15 21:27 28/Feb/13 19:38 3.2 3.2.2, 4.0-alpha1, 4.0     0 0   JDK 1.6/Windows/Eclipse Ganymede When set method is used to put element (Strawberry) on list, then it is possible to add the same element (Strawberry) with add method. Also you cannot add element (Lemon) that has been once removed with set method. Reproduction code below:


List<String> list = new LinkedList<String>();
SetUniqueList decoratedList = SetUniqueList.decorate(list);

decoratedList.add("Apple");
decoratedList.add("Lemon");
decoratedList.add("Orange");

System.out.println(decoratedList.toString());

decoratedList.set(1, "Strawberry");

System.out.println(decoratedList.toString());

decoratedList.add(1, "Strawberry");

System.out.println(decoratedList.toString());

decoratedList.add(1, "Lemon");

System.out.println(decoratedList.toString());
11 years, 20 weeks, 6 days ago 18697 No Perforce job exists for this issue. 2 164429 0|i0si7z:
Commons Collections COLLECTIONS-348

Javadoc: incorrect behavior explained for XXXUtils.transformedXXX

Bug Closed Major Fixed Unassigned Paul Benedict Paul Benedict 20/Dec/09 03:58   09/Nov/14 14:31 15/Oct/10 19:39 3.2 4.0-alpha1, 4.0 Bag, Collection, List, Map, Set   0 0   As a sequel to COLLECTIONS-288, any utility method that "transformed" needs to document that the incoming collection is not immediately transformed -- future additions are.

Candidate methods:
* BagUtils.transformedBag
* BagUtils.transformedSortedBag
* CollectionUtils.transform
* CollectionUtils.transformedCollection
* ListUtils.transformedList *done*
* MapUtils.transformedMap
* MapUtils.transformedSortedMap
* SetUtils.transformedSet
* SetUtils.transformedSortedSet
9 years, 23 weeks, 4 days ago 18655 No Perforce job exists for this issue. 0 164396 0|i0si0n:
Commons Collections COLLECTIONS-346

SetUniqueList.decorate throws exceptions that is not documented

Bug Closed Major Won't Fix Unassigned Jimmy Shi Jimmy Shi 24/Nov/09 23:18   19/Jun/10 19:41 19/Jun/10 19:41 3.2   List   0 0   public static void main(String[] args) {
List<String> testList=Arrays.asList("a","b","c","a","b","c","e");
SetUniqueList decoratedList = SetUniqueList.decorate(testList);
System.out.println(decoratedList);
}

throws below exception:
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:172)
at java.util.AbstractList$Itr.remove(AbstractList.java:437)
at java.util.AbstractList.removeRange(AbstractList.java:662)
at java.util.AbstractList.clear(AbstractList.java:258)
at org.apache.commons.collections.list.SetUniqueList.decorate(SetUniqueList.java:80)

caused by the list to decorate is unmodifiable.
9 years, 40 weeks, 3 days ago 18657 No Perforce job exists for this issue. 0 164397 0|i0si0v:
Commons Collections COLLECTIONS-310

Modifications of a SetUniqueList.subList() invalidate the parent list

Bug Closed Minor Fixed Unassigned Christian Semrau Christian Semrau 10/Jan/09 13:58 18/Mar/20 03:00 09/Nov/14 14:31 27/Apr/13 11:57 3.2, Nightly Builds 4.0-alpha1, 4.0 List   0 1   The List returned by SetUniqueList.subList() is again a SetUniqueList. The contract for List.subList() says that the returned list supports all the operations of the parent list, and it is backed by the parent list.

We have a SetUniqueList uniqueList equal to {"Hello", "World"}. We get a subList containing the last element. Now we add the element "Hello", contained in the uniqueList but not in the subList, to the subList.

What should happen?

Should the subList behave like a SetUniqueList and add the element - meaning that it changes position in the uniqueList because at the old place it gets removed, so now uniqueList equals {"World", "Hello"} (which fails)?
Or should the element not be added, because it is already contained in the parent list, thereby violating the SetUniqueList-ness of the subList (which fails)?
I prefer the former behaviour, because modifications should only be made through the subList and not through the parent list (as explained in List.subList()).

What should happen if we replace (using set) the subList element "World" with "Hello" instead of adding an element?

The subList should contain only "Hello", and for the parent list, the old element 0 (now a duplicate of the just set element 1) should be removed (which fails).

And of course the parent list should know what happens to it (specifically, its uniqueness Set) (which fails in the current snapshot).


public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.add("Goodbye");

List expectedSubList = Arrays.asList(new Object[] { "World", "Goodbye" });
List expectedParentList = Arrays.asList(new Object[] { "Hello", "World", "Goodbye" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains("Goodbye")); // fails
}

public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.add("Hello");

List expectedSubList = Arrays.asList(new Object[] { "World", "Hello" });
List expectedParentList = Arrays.asList(new Object[] { "World", "Hello" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}

public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.set(0, "Hello");

List expectedSubList = Arrays.asList(new Object[] { "Hello" });
List expectedParentList = Arrays.asList(new Object[] { "Hello" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
6 years, 47 weeks, 3 days ago 18691 No Perforce job exists for this issue. 5 90373 0|i0fth3:
Commons Collections COLLECTIONS-308

CollectionUtils.transform fails when collection is HashMap$Values

Bug Closed Minor Won't Fix Unassigned Lluís Martínez Lluís Martínez 23/Dec/08 23:32   24/Dec/08 14:19 24/Dec/08 14:19 3.2   Collection   0 0   Ubuntu I'm trying to apply a transformation to all values in a map :

Collection values = map.values();
CollectionUtils.transform(values, transformer);

Gives a java.lang.UnsupportedOperationException in CollectionUtils line 439.

According to Javadoc the method values of Hashmap "does not support the add or addAll operations.".


11 years, 13 weeks, 6 days ago 18693 No Perforce job exists for this issue. 0 164426 0|i0si7b:
Commons Collections COLLECTIONS-376

CollectionUtils.removeAll return retainAll - 3.2.1

Bug Closed Major Duplicate Unassigned Patrick Sauts Patrick Sauts 01/Jul/11 17:15 18/Mar/20 02:41 01/Jul/11 23:03 01/Jul/11 23:03 3.2   Collection   0 0   The code of removeAll method isn't correct

ligne 1121 of CollectionUtils
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
8 years, 38 weeks, 4 days ago 18627 No Perforce job exists for this issue. 0 164378 0|i0shwn:
Commons Collections COLLECTIONS-294

Fix case-insensitive string handling

Bug Closed Major Fixed Unassigned Benjamin Bentmann Benjamin Bentmann 25/Apr/08 14:31   07/Nov/15 21:17 28/Feb/13 19:38 3.2 3.2.2, 4.0-alpha1, 4.0 Map   0 0   For example, the behavior of the {{CaseInsensitiveMap}} is currently platform-dependent, please see [Common Bug #3|http://www.nabble.com/Re%3A-Common-Bugs-p14931921s177.html] for details. 11 years, 6 weeks, 1 day ago 18707 No Perforce job exists for this issue. 2 164438 0|i0si9z:
Commons Collections COLLECTIONS-279

LRUMap: moveToMRU is not invoked for new entry

Bug Closed Blocker Duplicate Unassigned Andrey Andreev Andrey Andreev 28/Nov/07 07:12   27/Nov/15 21:47 28/Feb/13 19:29 3.2   Map   2 1  
@Test
public void testFirst() {
LRUMap map = new LRUMap();

String key = "key1";
String value = "value1";

map.put(key, value);
Assert.assertEquals(map.get(key), value);
Assert.assertEquals(map.get(map.firstKey()), value);

key = "key2";
value = "value2";
map.put(key, value);
// here it fails
Assert.assertEquals(map.get(map.firstKey()), value);
}
12 years, 2 weeks, 3 days ago 18721 No Perforce job exists for this issue. 1 164449 0|i0sicf:
Commons Collections COLLECTIONS-278

put() and putAll() don't update the getKeys() map

Bug Closed Major Fixed Unassigned Henning Schmiedehausen Henning Schmiedehausen 13/Nov/07 21:24   27/Nov/15 21:11 28/Feb/13 20:05 3.2       0 0   If you use the put() or putAll() methods of the ExtendedProperties class, it will not update the contents of the internal keysAsListed map which in turn will return a different list of keys using the getKeys() method than the keySet() method does.

The attached patchs fix this behaviour and add test cases.
6 years, 48 weeks, 1 day ago 18722 No Perforce job exists for this issue. 4 164450 0|i0sicn:
Commons Collections COLLECTIONS-271

org.apache.commons.collections.ExtendedProperties#combine don't import string properly

Bug Closed Major Fixed Unassigned Alexander Borovsky Alexander Borovsky 16/Oct/07 12:40   27/Nov/15 21:11 28/Feb/13 19:56 3.2   Collection   1 1   When we set property with escaped characters, after combine propertySets we got them unescaped.

Simple Example

ExtendedProperties props = new ExtendedProperties();
props.setProperty("test", "\\\\\\\\192.168.1.91\\\\test");
props.getProperty("test"); // => \\192.168.1.91\test

ExtendedProperties props2 = new ExtendedProperties();
props2.combine(props);
props.getProperty("test"); // => \192.168.1.91\test -- Wrong!
6 years, 48 weeks, 1 day ago 18729 No Perforce job exists for this issue. 3 164455 0|i0sidr:
Commons Collections COLLECTIONS-284

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug Closed Major Duplicate Unassigned Chuck Deal Chuck Deal 30/Jan/08 21:01   05/Feb/08 05:47 05/Feb/08 05:47 3.2       0 0   CollectionUtils.removeAll() calls ListUtils.retainAll(). I believe it should actually be

public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.removeAll(collection, remove);
}
12 years, 8 weeks ago 18716 No Perforce job exists for this issue. 0 164445 0|i0sibj:
Commons Collections COLLECTIONS-353

AbstractLinkedMap firstKey/lastKey JavaDoc reversed

Bug Closed Major Duplicate Unassigned Michael Dürig Michael Dürig 23/Feb/10 10:15   27/Apr/13 21:26 19/Jun/10 19:28 3.2 4.0 Map   0 0   According to the Javadoc on AbstractLinkedMap#firstKey and AbstractLinkedMap#lastKey the following test shouldn't fail:

LinkedMap map = new LinkedMap();
map.put("one", "one");
map.put("two", "two");
assertEquals("one", map.lastKey());
assertEquals("two", map.firstKey());
9 years, 40 weeks, 3 days ago 18650 No Perforce job exists for this issue. 0 164392 0|i0shzr:
Commons Collections COLLECTIONS-350

MapUtils.getNumber sends output to System.out

Bug Closed Minor Fixed Unassigned Michael Akerman Michael Akerman 15/Jan/10 16:35   07/Nov/15 20:59 28/Feb/13 20:07 3.2 3.2.2, 4.0-alpha1, 4.0     0 0 3600 3600 0% MapUtils.getNumber calls "logInfo" on a ParseException and it produces output on the System.out, instead of just returning "null" as the documentation states.

Since the expected behavior is to return null, *not* print to System.out. I recommend we remove the call to logInfo and/or remove the System.out.println inside it.

At minimum, if that's not agreed upon, the "side-effect" of writing to System.out should be documented.

I'm happy to offer code for either of these fixes.
0% 0% 3600 3600 10 years, 10 weeks, 4 days ago 18653 No Perforce job exists for this issue. 0 164394 0|i0si07:
Commons Collections COLLECTIONS-349

The method CollectionUtils.removeAll() call wrongly ListUtils.retainAll()

Bug Closed Major Duplicate Unassigned Mathieu Mathieu 07/Jan/10 10:47   27/Apr/13 21:26 19/Jun/10 19:21 3.2 4.0 Collection   0 0   The method CollectionUtils.removeAll() calls wrongly ListUtils.retainAll() instead of ListUtils.removeAll().
9 years, 40 weeks, 3 days ago 18654 No Perforce job exists for this issue. 0 164395 0|i0si0f:
Commons Collections COLLECTIONS-266

Issue with MultiKey when serialized/deserialized via RMI

Bug Closed Minor Fixed Unassigned Julien Buret Julien Buret 11/Sep/07 21:02   07/Nov/15 20:54 28/Feb/13 19:57 3.2 3.2.2, 4.0-alpha1, 4.0 KeyValue   0 1   This is because the hash code of MultiKey is calculated only once.

So if the MultiKey is deserialized in an other jvm, and if one at least of the subkeys defines its hash code with System.identityHashCode() (for example all the enums does), then the hash code of the MultiKey is no longer valid, and you can't retreive the key in your Map.

I fixed it by making the cached hash code field transient, and by recalculating the hash code during deserialization.
11 years, 43 weeks, 4 days ago 18734 No Perforce job exists for this issue. 7 164459 0|i0sien:
Commons Collections COLLECTIONS-262

probably apidoc error: firstKey() and lastKey() in AbstractLinkedMap

Bug Closed Major Fixed Unassigned Lisen Mu Lisen Mu 29/Aug/07 04:10   09/Nov/14 14:31 28/Feb/13 19:28 3.2 4.0-alpha1, 4.0 Map   0 1   In the apidoc or source of org.apache.commons.collections.map.AbstractLinkedMap.firstKey(), it is said that this method "Gets the first key in the map, which is the most recently inserted.", which is exactly the actual behavior of lastKey(), and vice versa.

So I think there is a typo with this class' javadoc.
12 years, 12 weeks, 6 days ago 18738 No Perforce job exists for this issue. 0 164462 0|i0sifb:
Commons Collections COLLECTIONS-261

Flat3Map.remove() does not return the correct value when size <= 3

Bug Closed Major Fixed Unassigned ori ori 18/Aug/07 14:12   08/Nov/15 21:04 20/Aug/07 14:11 3.2 3.2.2, 4.0 Map   0 0   Windows XP, SUN JDK 1.5.0_06 final Flat3Map m = new Flat3Map();
m.put( new Integer( 1 ), new Integer( 1 ) );
m.put( new Integer( 0 ), new Integer( 0 ) );
System.out.println( m.remove( new Integer( 1 ) ) );

The above code will print "0" when it should print "1"
12 years, 32 weeks, 1 day ago 18739 No Perforce job exists for this issue. 1 164463 0|i0sifj:
Commons Collections COLLECTIONS-265

TreeBag allows uncomparable item to be added, breaking toString

Bug Closed Minor Fixed Unassigned David Saff David Saff 10/Sep/07 19:38   09/Nov/14 14:31 28/Feb/13 20:04 3.2 4.0-alpha1, 4.0 Bag   0 2   The following code throws an exception not when the Object is added, but when toString is called:

TreeBag bag = new TreeBag();
bag.add(new Object());
bag.toString();

Trace:

java.lang.ClassCastException: java.lang.Object
at java.util.TreeMap.compare(TreeMap.java:1093)
at java.util.TreeMap.getEntry(TreeMap.java:347)
at java.util.TreeMap.get(TreeMap.java:265)
at org.apache.commons.collections.bag.AbstractMapBag.getCount(AbstractMapBag.java:116)
at org.apache.commons.collections.bag.AbstractMapBag.toString(AbstractMapBag.java:581)
[...]

In a client program, toString should never throw an exception--it makes debugging much harder, for one thing. I believe that TreeBag should defend against the addition of uncomparable objects, so that toString will never throw an exception.
12 years, 6 days ago 18735 No Perforce job exists for this issue. 2 164460 0|i0siev:
Commons Collections COLLECTIONS-264

FastTreeMap forgets the comparator

Bug Closed Major Fixed Unassigned Thomas Louis Thomas Louis 30/Aug/07 16:24   28/Feb/13 19:31 31/Aug/07 09:39 3.2   Map   0 0   all In line 359 and 582 of the current 3.2 release you should replace
map = new TreeMap()
with
map = new TreeMap(map.comparator());

Otherwise the underlaying TreeMap looses ist comparator.
12 years, 30 weeks, 4 days ago 18736 No Perforce job exists for this issue. 0 164461 0|i0sif3:
Commons Collections COLLECTIONS-323

Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap

Bug Closed Minor Fixed Jochen Wiedmann Maarten Brak Maarten Brak 22/Apr/09 08:43   09/Nov/14 14:31 08/Mar/11 23:39 3.2 4.0-alpha1, 4.0 Map   0 2 86400 86400 0% Any The constructor CaseInsensitiveMap(int initialCapacity) throws an IllegalArgumentException if "the initial capacity is less than one". This is inconsistent with the standard Java HashMap constructor HashMap(int initialCapacity), which throws an if IllegalArgumentException if "the initial capacity is negative".

Thus:
new HashMap(0) ==> no exception
new CaseInsensitiveMap(0) ==> IllegalArgumentException.

This inconsistency is confusing.


Actions:
- Change Javadoc (this shouldn't be a problem in practice since surely there is no code around depending on the fact that the constructor throws an IllegalArgumentException :-))
- Change code.
0% 0% 86400 86400 7 years, 34 weeks, 5 days ago 18678 No Perforce job exists for this issue. 1 164415 0|i0si4v:
Commons Collections COLLECTIONS-307

SetUniqueList.subList().contains() method checks against full parent list, not sublist range

Bug Closed Minor Fixed Unassigned Christian Semrau Christian Semrau 12/Nov/08 16:59   08/Nov/15 21:12 28/Feb/13 20:03 3.2 3.2.2, 4.0-alpha1, 4.0 List   0 0   The view returned by the subList() method of a SetUniqueList checks contains() against the set of the original list.

As shown by the following test snippet.

List list = new ArrayList();
List uniqueList = SetUniqueList.decorate(list);
uniqueList.add("Hello");
uniqueList.add("World");
List subList = list.subList(0, 0);
List subUniqueList = uniqueList.subList(0, 0);
assertFalse(subList.contains("World")); // passes
assertFalse(subUniqueList.contains("World")); // fails
11 years, 12 weeks, 1 day ago 18694 No Perforce job exists for this issue. 1 164427 0|i0si7j:
Commons Collections COLLECTIONS-256

ListUtils.transformedList(list, transformer) doesn't transform

Bug Closed Major Duplicate Unassigned Kurtis Williams Kurtis Williams 08/Jun/07 22:43   09/Nov/14 14:31 27/Apr/13 21:42 3.2 4.0-alpha1, 4.0 List   0 0   Java 1.5 The static method ListUtils.transformedList(List list, Transformer trans) does not apply the transformer before returning the list. I've traced into the code and it falls all the way through to the TransformedCollection constructor which has documentation that states that items existing in the list are NOT transformed. This yields bizarre unexpected behavior for this method.

Conversely, the ListUtils.predicatedList(List list, Predicate pred) DOES apply the predicate. These methods are very similar but behave inconsistently.

If the transformer is not applied to the list, the method's usefulness is somewhat limited and causes the user to create an extra unwanted list in some circumstances:

// To transform an existing list
List myList = ... some list to be transformed ...
List transformed = ListUtils.transformedList(new ArrayList(), myTransformer);
transformed.addAll(myList);

I would expect a much shorter implementation such as:

List transformed = ListUtils.transformedList(myList, myTransformer)
12 years, 29 weeks, 6 days ago 18744 No Perforce job exists for this issue. 1 164467 0|i0sigf:
Commons Collections COLLECTIONS-257

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug Closed Major Duplicate Unassigned Sami Kallio Sami Kallio 25/Jun/07 10:53   27/Apr/13 21:26 26/Jun/07 15:40 3.2 4.0 Collection   0 0   /**
* Returns a collection containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>.
*
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>Collection</code> containing all the elements of <code>collection</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection retainAll(Collection collection, Collection retain) {
return ListUtils.retainAll(collection, retain);
}

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}


I guess the later method shoud be:
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.removeAll(collection, remove);
}
12 years, 40 weeks ago 18743 No Perforce job exists for this issue. 0 164466 0|i0sig7:
Commons Collections COLLECTIONS-315

CollectionUtils.removeAll calls the wrong ListUtils method

Bug Closed Major Duplicate Unassigned Christopher Christopher 03/Feb/09 19:30   01/May/12 12:03 03/Feb/09 20:40 3.2   Core   0 0   Using version 3.2.1 as downloaded from maven's public repository.

CollectionUtils.removeAll should call ListUtils.removeAll instead of ListUtils.retainAll.

Currently
{{public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}}}

Suggested
{{public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.*removeAll*(collection, remove);
}}}
7 years, 47 weeks ago 18686 No Perforce job exists for this issue. 0 164422 0|i0si6f:
Commons Collections COLLECTIONS-236

CollectionUtils.filter filters the inverse of what it is documented to filter

Bug Closed Major Invalid Unassigned Lee Wexler Lee Wexler 21/Nov/06 14:12   22/Nov/06 16:26 22/Nov/06 16:26 3.2   Collection   0 1   The documentation states that when the predicate returns *false* the item will be removed.
The implementation removes those items that return true.

13 years, 18 weeks, 6 days ago 18763 No Perforce job exists for this issue. 0 164482 0|i0sijr:
Commons Collections COLLECTIONS-246

LoopingListIterator behaves unexpected on next and previous mixed

Bug Closed Blocker Invalid Unassigned Frank Hefter Frank Hefter 20/Mar/07 09:07   28/Feb/13 19:52 26/Apr/08 15:17 3.2   Iterator   0 2   JDK 1.4.2_12
Common Collections 3.2
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of "cursor" var seems to be wrong implemented ) to cause this problem. If so maybe we have to implement it in a different way.

Testcase (it runs without hassle but the comments show whats wrong):
-------------------------------------------
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;

public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add("0"); al.add("1"); al.add("2");
LoopingListIterator it = new LoopingListIterator(al);
assertEquals("0", it.next()); // This is OK
// here I am on "0"
assertEquals("0", it.previous()); // Wrong ! This should be 2!
// here I am on "0" too! This is wrong.
assertEquals("2", it.previous());
assertEquals("1", it.previous());
assertEquals("0", it.previous());
assertEquals("2", it.previous());
// here I am on "2"
assertEquals("2", it.next()); // Wrong ! This should be 0!
// here I am on "2" too! This is wrong.
assertEquals("0", it.next());
assertEquals("1", it.next());
// here I am on "1"
assertEquals("1", it.previous()); // Wrong ! This should be 0!
}
}
-------------------------------------------

Thanks for your help.
11 years, 48 weeks, 3 days ago 18753 No Perforce job exists for this issue. 3 164475 0|i0sii7:
Commons Collections COLLECTIONS-249

SetUniqueList.addAll(int index, Collection coll) adds to end of list instead of at specified index

Bug Closed Minor Fixed Unassigned Joe Kelly Joe Kelly 20/Apr/07 19:10   07/Nov/15 20:26 28/Feb/13 20:05 3.2 3.2.2, 4.0-alpha1, 4.0 List   0 1   When you call SetUniqueList.addAll(int index, Collection coll), it incorrectly adds the new elements to the end of the list instead of at the specified index. 12 years, 10 weeks, 2 days ago 18750 No Perforce job exists for this issue. 2 164473 0|i0sihr:
Commons Collections COLLECTIONS-240

MultiValueMap should implement Serializable

Bug Closed Blocker Fixed Unassigned Wouter de Vaal Wouter de Vaal 20/Jan/07 14:09   09/Nov/14 14:31 28/Feb/13 20:04 3.2 4.0-alpha1, 4.0 Map   11 6   Collection classes should be serializable as they are frequently used in model classes which need to be serializable, for example in a HttpSession object within a servlet container cluster. 11 years, 44 weeks, 4 days ago 18759 No Perforce job exists for this issue. 1 163862 0|i0seq7:
Commons Collections COLLECTIONS-239

In LinkIterator hasPrevious() is not working properly for the first entry

Bug Closed Major Won't Fix Unassigned Michael Pavlov Michael Pavlov 17/Jan/07 09:26   27/Apr/13 21:25 26/Mar/08 05:36 3.2   Iterator   0 1   Windows XP, jdk-1.5.0_02 In hasPrevious() method of LinkIterator 'next' field is used, that is not correct - method returns 'true' for the first entry. 'last' field should be used insted. 7 years, 34 weeks, 5 days ago 18760 No Perforce job exists for this issue. 1 164480 0|i0sijb:
Commons Collections COLLECTIONS-237

MultiValueMap: behavior of entrySet().iterator() is not the expected one

Bug Closed Major Fixed Unassigned Nils Kaiser Nils Kaiser 12/Dec/06 18:09   09/Nov/14 14:31 27/Apr/13 11:09 3.2 4.0-alpha1, 4.0 Map   1 0   The entrySet() method of the MultiValueMap delegates the entrySet() call to the decorated map, which is HashMap by default. The default hashmap iterator is used, which causes the iterator to return one Map.Entry for every key. The value returned for the key is an ArrayList, and not the value of the entry which was put into the map.

The expected behavior would be the iterator to return the whole set of entries in the map, which requires iteration over the different array lists contained in the decorated map.
6 years, 47 weeks, 3 days ago 18762 No Perforce job exists for this issue. 0 90387 0|i0ftk7:
Commons Collections COLLECTIONS-228

MultiValueMap put and putAll do not return the correct values

Bug Closed Minor Fixed Stephen Colebourne Stephen Colebourne Stephen Colebourne 28/Oct/06 12:14   07/Nov/15 20:47 28/Feb/13 20:25 3.2 3.2.2, 4.0-alpha1, 4.0 Map   0 0   MultiValueMap put and putAll do not return the correct values.

putAll(Object, Collection) should return true if the map is changed. But if the key is new then this behaviour fails.

put(Object, Object) should return the added value if the map is changed. But if the key is new then this behaviour fails.

This was hidden because the test case referred to MultiHashMap and not MultValueMap.
13 years, 22 weeks, 3 days ago 18771 No Perforce job exists for this issue. 0 164490 0|i0silj:
Commons Collections COLLECTIONS-221

CompositeCollection, CompositeMap, CompositeSet should implement Serializable

Bug Closed Minor Fixed Unassigned Pal Denes Pal Denes 12/Aug/06 17:10   09/Nov/14 14:31 28/Feb/13 20:08 3.2 4.0-alpha1, 4.0 Collection, Map, Set   1 1   These classes should implement Serializable as usually all generial collection classes do. (At least I cannot think of a reason why they shouldn't and currently their usage is quite limited, like in RMI or http-sessions.) 11 years, 46 weeks ago 18778 No Perforce job exists for this issue. 1 164494 0|i0simf:
Commons Collections COLLECTIONS-222

CollectionUtils removeAll is actually retainAll

Bug Closed Major Duplicate Unassigned Tim Lenz Tim Lenz 18/Aug/06 17:43   18/Aug/06 19:01 18/Aug/06 19:01 3.2   Collection   0 0   The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove)
instead of ListUtils.removeAll(Collection collection, Collection remove)

Should be an easy fix
13 years, 32 weeks, 4 days ago 18777 No Perforce job exists for this issue. 0 164493 0|i0sim7:
Commons Collections COLLECTIONS-219

The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method.

Bug Closed Major Fixed Stephen Colebourne Tom Leccese Tom Leccese 02/Aug/06 17:37   07/Nov/15 19:51 28/Feb/13 20:25 3.2 3.2.2, 4.0-alpha1, 4.0 Core   0 4   The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method. 4 years, 19 weeks, 3 days ago 18780 No Perforce job exists for this issue. 0 115442 0|i0k3uv:
Commons Collections COLLECTIONS-217

Flat3Map.Entry.setValue() overwrites other Entry values

Bug Closed Critical Fixed Stephen Colebourne Matt Bishop Matt Bishop 18/Jul/06 17:42   08/Nov/15 20:21 18/Jul/06 22:02 3.2 3.2.2, 4.0 Map   1 0   JDK 1.4, WinXP Flat3Map's Entry objects will overwrite other Entry's values if Entry.setValue() is called on one. It should only overwrite the Entry at hand.

I've looked at the source, and the case statement incorrectly falls through, rather than returning like it should:

Flat3Map.java, lines 646-660:

public Object setValue(Object value) {
if (canRemove == false) {
throw new IllegalStateException(AbstractHashedMap.SETVALUE_INVALID);
}
Object old = getValue();
switch (nextIndex) {
case 3:
parent.value3 = value;
case 2:
parent.value2 = value;
case 1:
parent.value1 = value;
}
return old;
}

With this code, if I set the value of the third item in the EntrySet, then all three values are set to the new value.
13 years, 37 weeks ago 18782 No Perforce job exists for this issue. 0 164497 0|i0sin3:
Commons Collections COLLECTIONS-220

Serialization/Deserialization doesn't work well with empty buffers.

Bug Closed Minor Fixed Unassigned Jose Luis Huertas Jose Luis Huertas 07/Aug/06 13:53   27/Nov/15 21:11 28/Feb/13 20:08 3.2   Buffer   1 1   When I serialize the queue to disk an it has elements, all works ok, but when I serialize an empty queue I have some problems when I create a new object using the serialized file.

When I deserialize the queue it has a 'buffer' with size 1 (with null content), 'tail' and 'head' fields are 0 (they are declared transient). So, when I try to add a new object to the queue, the sentence:

Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];

Is executed in the add() method to increase the buffer length, but the buffer remains with the same size! (buffer.length = 1 --> (1 - 1) * 2 + 1 = 1). So, the object is added and when the tail is going to be incremented, it is reset to 0!!

private int increment(int index) {
index++;
if (index >= buffer.length) {
index = 0;
}
return index;
}


So it is impossible to add new elements after an empty queue has been serialized / deserialized.

I attach a simple TestCase where this is proved. The example works when you use XMLEncoder to serialize the buffer but doesn't work if you use ObjectOutputStream or XStream.
6 years, 48 weeks, 1 day ago 18779 No Perforce job exists for this issue. 3 164495 0|i0simn:
Commons Collections COLLECTIONS-214

ExtendedProperties - field include should be non-static and private

Bug Closed Major Fixed Stephen Colebourne Sebb Sebb 18/Jun/06 18:54   27/Apr/13 21:32 18/Jul/06 22:44 3.2       0 0   The field "include" in ExtendedProperties is currently static and protected, yet has instance get/set accessors.

Given that there are accessors, it seems unnecessary for the field to be protected - it could be private.

The field should also surely be non-static - or the accessors should be made static, if the field really is supposed to be shared among instances.
6 years, 47 weeks, 3 days ago 18785 No Perforce job exists for this issue. 0 164500 0|i0sinr:
Commons Collections COLLECTIONS-87

[collections] Implement a TimeoutBuffer class

Bug Closed Major Won't Fix Unassigned James Carman James Carman 12/Nov/05 05:35   15/Mar/08 21:36 15/Mar/08 21:36 3.2       0 0   Operating System: other
Platform: Other
Please implement a TimeoutBuffer wrapper class which blocks on read()/get()
operations until a timeout expires.
14 years, 18 weeks, 6 days ago 18911 No Perforce job exists for this issue. 0 37472 164621 0|i0sjen:
Commons Collections COLLECTIONS-17

[collections] Enhance BlockingBuffer to allow for a timeout value

Bug Closed Major Fixed Unassigned James Carman James Carman 23/Nov/05 22:00   15/Mar/08 21:35 15/Mar/08 21:35 3.2       0 0   Operating System: other
Platform: Other
BlockingBuffer currently waits forever. Add the capability to specify a timeout
value to BlockingBuffer.
14 years, 18 weeks, 6 days ago 18981 No Perforce job exists for this issue. 0 37607 164691 0|i0sju7:
Commons Collections COLLECTIONS-29

[collections] "Upload to m2 repo @ibiblio.org"

Bug Closed Major Invalid Unassigned David J. M. Karlsen David J. M. Karlsen 15/May/06 21:27   18/Jul/06 22:04 18/Jul/06 22:04 3.2       0 1   Operating System: other
Platform: Other
Could somebody upload collections 3.2 to www.ibiblio.org/maven2 repo?
13 years, 37 weeks ago 18969 No Perforce job exists for this issue. 0 39584 164679 0|i0sjrj:
Commons Collections COLLECTIONS-116

[collections] Getting rid of some javadoc warn messages (3.2-dev)

Bug Closed Minor Fixed Unassigned Olaf Krische Olaf Krische 04/Oct/04 06:07   15/Mar/08 21:36 15/Mar/08 21:36 3.2 3.2     0 0   Operating System: other
Platform: Other
Salut.

Just called javadoc to create the java documentation and wondered about
some warnings, though everything seemed to be at the right place:

Tag @link: can't find removeLRU(LinkEntry) in
org.apache.commons.collections.map.LRUMap
Tag @link: can't find moveToMRU(LinkEntry) in
org.apache.commons.collections.map.LRUMap

"LinkEntry" is a static class in AbstractLinkedMap, LRUMap derives from
AbstractLinkedMap. Why javadoc does not know about "LinkEntry" then, while
java itself does?

The solution comes from the javadoc-API:

"Nested classes must be specified as outer.inner, not simply inner, for all forms."

(http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#@see)

That is the reason, why javadoc spews warnings, when {@link
#removeLRU(LinkEntry)} is used.

The correct code will look like this then:

{@link #removeLRU(AbstractLinkedMap.LinkEntry)}

Actually i have found this only in collections.map.LRUMap, its really a minor
thing. But even Eclipse gave me the "wrong" code...

Thanks for the collections, we use them intensily here :-)

Ciao.
15 years, 13 weeks ago 18882 No Perforce job exists for this issue. 9 31519 164592 0|i0sj87:
Commons Collections COLLECTIONS-52

[collections] Method that add a Object to a Collection if it was not null

Bug Closed Major Fixed Unassigned Rafael U. C. Afonso Rafael U. C. Afonso 10/Jul/04 08:52   15/Mar/08 21:35 15/Mar/08 21:35 3.2       0 0   Operating System: other
Platform: Other
It would be a new static method to CollectionUtils class. It would retur
boolean because add() method from Collection returns a boolean. It would had
only a line:

public static boolean addNotNull(Collection c, Object o) {
return (o != null)? c.add(o): false;
}

Of course if c was null, it will throw a NullPointerException.
Aparently it is possible use a PredicatedCollection with NotNullPredicate. But
it will trhow a IllegalArgumentException if o was null. It is not interesting.
15 years, 37 weeks, 2 days ago 18946 No Perforce job exists for this issue. 0 30020 164656 0|i0sjmf:
Commons Collections COLLECTIONS-379

Bugs In Javadoc Comment in the CollectionUtils class

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 22/Sep/11 02:45 18/Mar/20 02:41 09/Nov/14 14:31 26/Jul/12 21:19 3.2 4.0-alpha1, 4.0 Collection   0 2 1200 1200 0% System independent I came across the following bugs in the Javadoc comments in the method below in the CollectionUtils class:

1.
{quote}
/**
* Selects all elements from input collection which match the given predicate
* and adds them to outputCollection.
* <p>
* If the input collection or predicate is null, there is no change to the
* output collection.
*
* @param inputCollection the collection to get the input from, may be null
* @param predicate the predicate to use, may be null
* @*param outputCollection the collection to output into, may not be null*
*/
public static void select(Collection inputCollection, Predicate predicate, Collection outputCollection) {
{quote}
_This method will execute normally when calling select((Collection)null, (Predicate)null, (Collection)null) but the comment clearly states that outputCollection may not be null_

2.
{quote}
/**
* Selects all elements from inputCollection which don't match the given predicate
* and adds them to outputCollection.
* <p>
* If the input predicate is <code>null</code>, no elements are added to <code>outputCollection</code>.
*
* @param inputCollection the collection to get the input from, may be null
* @param predicate the predicate to use, may be null
* @*param outputCollection the collection to output into, may not be null*
*/
public static void selectRejected(Collection inputCollection, Predicate predicate, Collection outputCollection) {
{quote}
_This method will execute normally when calling selectRejected((Collection)null, (Predicate)null, (Collection)null) but the comment also clearly states that outputCollection may not be null_

3.
{quote}
/**
* Transforms all elements from the inputIterator with the given transformer
* and adds them to the outputCollection.
* <p>
* If the input iterator or transformer is null, there is no change to the
* output collection.
*
* @param inputIterator the iterator to get the input from, may be null
* @param transformer the transformer to use, may be null
* @*param outputCollection the collection to output into, may not be null*
* @return the outputCollection with the transformed input added
* @*throws NullPointerException if the output collection is null*
*/
public static Collection collect(Iterator inputIterator, final Transformer transformer, final Collection outputCollection) {
{quote}
_This method will execute normally when calling collect((Iterator)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_

4.
{quote}
/**
* Transforms all elements from inputCollection with the given transformer
* and adds them to the outputCollection.
* <p>
* If the input collection or transformer is null, there is no change to the
* output collection.
*
* @param inputCollection the collection to get the input from, may be null
* @param transformer the transformer to use, may be null
* @*param outputCollection the collection to output into, may not be null*
* @return the outputCollection with the transformed input added
* @*throws NullPointerException if the output collection is null*
*/
public static Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) {
{quote}
_This method will execute normally when calling collect((Collection)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_


The bugs in the Javadoc comments above could be confusing to the users of the Common Collection library and they could be fixed easily by the developers..


There are a few ways to fix the:
1. Throwing the NullPointerException explicitly when the outputCollection is null.
2. Changing the Javadoc comments to include the case where all of the parameters are null.
0% 0% 1200 1200 test
7 years, 34 weeks, 5 days ago 3625 No Perforce job exists for this issue. 0 164375 0|i0shvz:
Commons Collections COLLECTIONS-652

An obvious bug in CollectionUtils

Bug Closed Minor Fixed Unassigned samray leung samray leung 12/Jul/17 08:49   02/Aug/17 16:50 02/Aug/17 16:50 3.2.1 3.2.2 Collection   0 1 600 600 0% windows 7, jdk8. This bug is so obvious so I think it is nothing to do with environment In CollectionUtils.java:
Line number: 1121

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
The method should call ListUtils.removeAll(Collection collection, Collection remove) instead of calling ListUtils.retailAll(collection,remove)
0% 0% 600 600 easyfix
2 years, 32 weeks, 6 days ago 9223372036854775807 /**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
No Perforce job exists for this issue. 0 9223372036854775807
Patch, Important
0|i3hf0f:
Commons Collections COLLECTIONS-538

ExtendedProperties causes AccessControlException when framework is called from a script

Bug Closed Major Fixed Unassigned Trejkaz Trejkaz 03/Dec/14 23:58   27/Nov/15 21:11 08/Nov/15 15:08 3.2.1 3.2.2 Collection   0 1   Java security manager enabled We're using Velocity 1.7, which depends upon Commons Collections 3.x series' ExtendedProperties class.

ExtendedProperties has these constructors where it looks up the file separator using the least convenient means possible:

{code}
public ExtendedProperties() {
this.fileSeparator = System.getProperty("file.separator");
// ...
}
{code}

For us, this is all being called from untrusted code, so this fails with AccessControlException.

I think that instead of using the system property here, it is customary to use the File.separator constant.

If you absolutely _must_ use System.getProperty() to fetch this value, it should at least be done from a doPrivileged() block.

Also I had a quick check of Commons Collections 4 to see if this issue had been fixed, but couldn't immediately see what happened to this class. If it did turn out to have been fixed in v4, maybe Velocity could be encouraged to update to v4, but I haven't seen any updates from them in 4 years, so it's probably not a good sign.

4 years, 19 weeks, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i231d3:
Commons Collections COLLECTIONS-444

SetUniqueList may become inconsistent

Bug Closed Major Fixed Unassigned Thomas Vahrst Thomas Vahrst 25/Feb/13 16:08   08/Nov/15 21:36 17/Apr/13 18:13 3.2.1 3.2.2, 4.0-alpha1, 4.0 List   0 2   I found this bug during my work on issue COLLECTIONS-310 :

When you 'set' an element to a position that contains this element, it is removed from the internal set. This leads to the situation that
- invocing get() returns the element
- invocing contains() returns false.

Extending the existing test method for set:
{code}
public void testSet() {
final SetUniqueList<E> lset = new SetUniqueList<E>(new ArrayList<E>(), new HashSet<E>());

// Duplicate element
final E obj1 = (E) new Integer(1);
final E obj2 = (E) new Integer(2);
final E obj3 = (E) new Integer(3);

lset.add(obj1);
lset.add(obj2);
lset.set(0, obj1);
assertEquals(2, lset.size());
assertSame(obj1, lset.get(0));
assertSame(obj2, lset.get(1));

assertTrue(lset.contains(obj1)); // fails !
assertTrue(lset.contains(obj2));

{code}


6 years, 48 weeks, 6 days ago 314421 No Perforce job exists for this issue. 0 314766 0|i1i9av:
Commons Collections COLLECTIONS-407

ListOrderedSet.removeAll() is slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 01/Jun/12 17:55   09/Nov/14 14:31 19/Jun/12 19:00 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListOrderedSet.removeAll().
It appears in version 3.2.1 and also in revision 1344775 (31 May
2012). I have attached a test that exposes this problem and a
one-line patch that fixes it. On my machine, for this test, the patch
provides a 317X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 3812

The output for the patched version is:
Time is 12

As the patch shows, the problem is in
ListOrderedSet.remove(Object object). The code for this method is:

boolean result = collection.remove(object);
setOrder.remove(object);
return result;

The patch changes it to :

boolean result = collection.remove(object);
if (result) setOrder.remove(object);
return result;

The "setOrder.remove(object)" is not necessary if
"collection.remove(object)" did not find the object.

This small change speeds up
ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) because
ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) iterates
over all the elements in "coll" and calls
ListOrderedSet.remove(Object object). So the un-patched code has
quadratic complexity, while the patched code has linear complexity.

Is this truly a bug, or am I missing something here? If so, can you
please confirm if the patch is correct?

Thanks,

Adrian
7 years, 40 weeks ago 292951 No Perforce job exists for this issue. 2 164353 0|i0shr3:
Commons Collections COLLECTIONS-406

ListUtils.subtract is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 27/May/12 19:52   09/Nov/14 14:31 03/Jun/12 10:25 3.2.1 4.0-alpha1, 4.0     0 3   java 1.6.0_24
Ubuntu 11.10
Hi,

ListUtils.subtract is very slow when subtracting two large lists. The
root cause of this problem is similar to the root cause of the
previously fixed COLLECTIONS-328 in ListUtils, i.e., quadratic
complexity instead of linear complexity.

I am encountering this problem in version 3.2.1 and also in revision
1342815 (May 25th 2012). I have attached a test that exposes this
problem and a simple patch. On my machine, for the attached test,
this patch provides a 95X speedup.

To run the test, just do:

$ java Test

Currently, the code for ListUtils.subtract is:

final ArrayList<E> result = new ArrayList<E>(list1);
for (E e : list2) {
result.remove(e);
}
return result;

which is quadratic, because result.remove(e) has linear complexity.

The attached patch makes the remove() be constant complexity by
removing from an org.apache.commons.collections.bag.HashBag. I use
HashBag and not HashSet because ListUtils.subtract needs to respect
the cardinality when there are repeated objects in the list.

As mentioned in COLLECTIONS-328 discussion, for small lists, there is
some overhead for creating the HashBag. This can be fixed with a
threshold, but I did not implement it in my patch because the
COLLECTIONS-328 patch does not implement it.

Unlike the patch for COLLECTIONS-328, my patch does not choose the
list to iterate over based on size, because of the cardinality
requirement in subtract. This means the code could be made even
faster if we could use something like a LinkedHashBag but neither
Apache Collections nor standard Java libraries have such a class.
Even so, this patch is still a lot faster than the original version.

Is this truly a bug, or am I missing something here? If so, can you
please confirm if the patch is correct?

Thanks,

Adrian


7 years, 42 weeks, 2 days ago 292952 No Perforce job exists for this issue. 2 164354 0|i0shrb:
Commons Collections COLLECTIONS-401

Inconsistent Javadoc comment and code in removeAll(Collection<E>, Collection<?>) in org.apache.commons.collections.ListUtils

Bug Closed Major Not A Problem Unassigned SHIN HWEI TAN SHIN HWEI TAN 30/Mar/12 03:02   27/Nov/15 21:47 26/Jul/12 21:02 3.2.1   Collection   0 1 180 180 0% The Javadoc comment below states that the method "throws NullPointerException if either parameter is null".
/*......
*
* @throws NullPointerException if either parameter is null
*/
public static <E> List<E> removeAll(Collection<E> collection, Collection<?> remove) {
..
}
However, when called with two null collections (i.e., "removeAll((Collection)null, (Collection)null)"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if either parameter is null" from the Javadoc.
or
3. Change "@throws NullPointerException if either parameter is null" to "@throws NullPointerException if the first collection is null or (the first collection is non-empty and the second collection is null)".
0% 0% 180 180 javadoc
7 years, 39 weeks, 6 days ago 233875 No Perforce job exists for this issue. 0 164358 0|i0shs7:
Commons Collections COLLECTIONS-400

Inconsistent Javadoc comment and code in addIgnoreNull(Collection<T>, T) in org.apache.commons.collections.CollectionUtils

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 30/Mar/12 02:59   09/Nov/14 14:31 09/Apr/12 17:27 3.2.1 4.0-alpha1, 4.0 Collection   0 0 180 180 0% Platform independent The Javadoc comment below states that the method "throws NullPointerException if the collection is null".
/**
.....
* @param collection the collection to add to, must not be null
* @param object the object to add, if null it will not be added
* @return true if the collection changed
* @throws NullPointerException if the collection is null
*/
public static <T> boolean addIgnoreNull(Collection<T> collection, T object) {
return (object != null && collection.add(object));
}
However, when called with an null collection and a null object (i.e., "addIgnoreNull((Collection)null, null)"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if the collection is null" from the Javadoc.
or
3. Change "@throws NullPointerException if the collection is null" to "@throws NullPointerException if the collection is null and the object is non-null)".
0% 0% 180 180 javadoc 7 years, 50 weeks, 1 day ago 233874 No Perforce job exists for this issue. 0 164359 0|i0shsf:
Commons Collections COLLECTIONS-402

Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils

Bug Closed Major Invalid Unassigned SHIN HWEI TAN SHIN HWEI TAN 30/Mar/12 03:42   27/Nov/15 21:47 26/Jul/12 20:59 3.2.1   Collection   0 0 180 180 0% Platform Independent The Javadoc comment below states that the method "throws NullPointerException if either list is null".
/*......
*
* @throws NullPointerException if either list is null
*/
public static List intersection(final List list1, final List list2)
..
}
However, when called with a null list1 and an empty list2(i.e., "intersection((List)null, new ArrayList())"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (list1 == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if either list is null" from the Javadoc.
or
3. Change "@throws NullPointerException if either list is null" to "@throws NullPointerException if list2 is null or (the list2 is non-empty and the list1 is null)".
0% 0% 180 180
7 years, 50 weeks, 1 day ago 233877 No Perforce job exists for this issue. 0 164357 0|i0shrz:
Commons Collections COLLECTIONS-472

wasted work in AbstractMapBag.containsAll()

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 03/Jun/13 22:59   09/Nov/14 14:31 09/Jun/13 18:35 3.2.1 4.0-alpha1, 4.0 Bag   0 1   any The problem appears in version 3.2.1 and in revision 1489197. I
attached a one-line patch that fixes it.

In method "AbstractMapBag.containsAll", the loop over
"other.uniqueSet()" should return immediately after "result" becomes
"false", because "result = result && contains;" can never become
"true" again. All the iterations after "result" becomes "false" do
not perform any useful work, at best they just set "result" again to
"false".
patch,, performance 6 years, 41 weeks, 2 days ago 331088 No Perforce job exists for this issue. 1 331421 0|i1l4an:
Commons Collections COLLECTIONS-453

findBugs Warnings: several classes in package functors may expose their internal representation

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 27/Apr/13 12:23   09/Nov/14 14:31 05/May/13 16:16 3.2.1 4.0-alpha1, 4.0     0 0   Several classes (e.g. SwitchTransformer) take in their constructor an array as input which is not copied/cloned.
Thus its internal representation may be changed externally.

The corresponding factory methods *do* copy the input arguments thus we have two choices:

* move the copy from the factory methods to the ctors
* make the ctors private to prevent their use
6 years, 46 weeks, 2 days ago 325382 No Perforce job exists for this issue. 0 325727 0|i1k4wv:
Commons Collections COLLECTIONS-454

findBugs Warning: Flat3Map - 3 iterators which are "both an Iterator and a Map.Entry"

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 27/Apr/13 12:26   09/Nov/14 14:31 28/Apr/13 18:53 3.2.1 4.0-alpha1, 4.0     0 0   The iterators should be rewritten as suggested by findbugs. 6 years, 47 weeks, 2 days ago 325383 No Perforce job exists for this issue. 1 325728 0|i1k4x3:
Commons Collections COLLECTIONS-435

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug Closed Major Duplicate Unassigned Mikolaj Rydzewski Mikolaj Rydzewski 14/Nov/12 10:13   14/Nov/12 10:26 14/Nov/12 10:26 3.2.1   Collection   0 1   A snippet from CollectionUtils.java:

{code:title=CollectionUtils.java}
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
{code}
It should call ListUtils.removeAll() instead.
7 years, 18 weeks, 6 days ago 257655 No Perforce job exists for this issue. 0 115439 0|i0k3u7:
Commons Collections COLLECTIONS-425

performance problem in ListOrderedMap.remove()

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 24/Jul/12 18:15   09/Nov/14 14:31 25/Jul/12 21:15 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListOrderedMap.remove().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a simple patch that fixes it. On
my machine, for this test, the patch provides a 213X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 1497

The output for the patched version is:
Time is 7

The patch changes the "ListOrderedMap.remove(Object key)" code from:

{code:java|borderStyle=solid}
Object result = getMap().remove(key);
insertOrder.remove(key);
{code}

to:

{code:java|borderStyle=solid}
if (decorated().containsKey(key)) {
result = decorated().remove(key);
insertOrder.remove(key);
}
{code}

If "decorated()" does not contain the key, there is no need to remove
it. This change significantly speeds up the code by avoiding the call
to "insertOrder.remove(key)", which is very expensive because
"insertOrder" is an ArrayList, and removing from an ArrayList is a
linear time operation.

It may appear that the check "if (decorated().containsKey(key))" may
slow down the code when "decorated()" contains the key, because it
adds a new operation "decorated().containsKey(key)", without avoiding
the calls to "getMap().remove(key)" and "insertOrder.remove(key)".

I attached a test, TestWorstCase.java, that show that, even when
removing only existing keys (i.e., "decorated().containsKey(key)"
always returns "true"), the patched version takes almost the same time
as the un-patched version.

To run TestWorstCase, just do:

$ java TestWorstCase

The output for the un-patched version for TestWorstCase is:
Time is 96

The output for the patched version for TestWorstCase is:
Time is 97

The reason why the patch does not slow down the code, even for this
worst case, is because "decorated().containsKey(key)" is a
"containsKey()" on a HashMap (very fast, constant time operation),
whereas "insertOrder.remove(key);" is a "remove()" on an ArrayList
(very slow, linear time operation). So the time taken by
"decorated().containsKey(key)" is negligible compared to the time
taken by "insertOrder.remove(key);". In other words, most of the time
is spent inside "insertOrder.remove(key)", and performing one
additional fast operation cannot be noticed.

Is this truly a bug? If so, can you please confirm if the patch is
correct?

Thanks,

Adrian
7 years, 34 weeks, 6 days ago 292941 No Perforce job exists for this issue. 3 164343 0|i0shov:
Commons Collections COLLECTIONS-426

performance problem in ListOrderedSet.retainAll()

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 24/Jul/12 22:04   27/Nov/15 21:11 27/Jan/15 15:06 3.2.1 4.0-alpha1, 4.0, 4.1     0 1   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListOrderedSet.retainAll().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a patch that fixes it. On my
machine, for this test, the patch provides a 263X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 3682

The output for the patched version is:
Time is 14

The problem is that the code for method
"ListOrderedSet.retainAll(Collection<?> coll)" is:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> coll) {
boolean result = collection.retainAll(coll);
....
}
{code}

because "collection.retainAll(coll)" has quadratic complexity if
parameter "coll" is a List. Conceptually, the solution is to call
"coll.retainAll(collection)" which has linear complexity (not
quadratic), because "collection" is always a HashSet (we know this,
because "collection" is an inherited field of ListOrderedSet, and thus
cannot have another type). See the
"java.util.AbstractCollection.retainAll()" code inlined below for why
one call has quadratic complexity, and the other has linear
complexity.

Directly calling "coll.retainAll(collection)" would change the
behavior of ListOrderedSet.retainAll(), which is why the patch seems a
bit involved. In reality, the patch simulates the behavior of
"coll.retainAll(collection)" (which is just the intersection of two
collections). You can easily see this by looking at the patch and at
the "java.util.AbstractCollection.retainAll()" code inlined below.

"collection.retainAll(coll)" is "java.util.HashSet.retainAll()", which
is "java.util.AbstractCollection.retainAll()", which has the code:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> c) {
boolean modified = false;
Iterator<E> e = iterator();
while (e.hasNext()) {
if (!c.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
}
{code}


Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm if the patch is correct?

Thanks,

Adrian
5 years, 8 weeks ago 255280 No Perforce job exists for this issue. 2 84081 0|i0eqnr:
Commons Collections COLLECTIONS-427

performance problem in SetUniqueList.retainAll()

Bug Closed Major Fixed Unassigned Mert Guldur Mert Guldur 24/Jul/12 23:50   27/Nov/15 21:11 27/Jan/15 15:09 3.2.1 4.0-alpha1, 4.0, 4.1     0 2   java 1.6.0_24
Ubuntu 11.10
I am encountering a performance problem in SetUniqueList.retainAll().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a patch that fixes it. On my
machine, for this test, the patch provides a 621X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 6215

The output for the patched version is:
Time is 10

There are two problems here. First, "SetUniqueList.retainAll()"
should have similar implementation with the current implementation of
"ListOrderedSet.retainAll()", which is more optimized. Second, even
"ListOrderedSet.retainAll()" has a performance problem, which was
reported and explained in detail in COLLECTIONS-426.

The attached patch has two parts. The first part (the first loop) is
inspired from COLLECTIONS-426. The second part (everything after the
first loop) is in fact the current implementation of
"ListOrderedSet.retainAll()", with some minor changes to adapt it for
the current code. Overall, the attached patch is very similar to the
COLLECTIONS-426 patch.

I will rehash some of the information from COLLECTIONS-426 (which
describes "ListOrderedSet.retainAll()") for the current
"SetUniqueList.retainAll()".

The current code for "SetUniqueList.retainAll()" is:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> coll) {
boolean result = super.retainAll(coll);
set.retainAll(coll);
return result;
}
{code}

where both "super.retainAll(coll)" and "set.retainAll(coll)" can have
quadratic complexity, e.g., if "coll" is a List. Both these calls to
"retainAll" are in fact calls to
"java.util.AbstractCollection.retainAll()", which has the code:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> c) {
boolean modified = false;
Iterator<E> e = iterator();
while (e.hasNext()) {
if (!c.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
}
{code}

which iterates over "this" and calls "contains()" on "c". Mapping
this code back to "SetUniqueList.retainAll()" means that the code
iterates over "this" and "set" and calls "contains()" on "coll". If
"coll" has slow "contains()" (e.g., if "coll" is a list), then
"SetUniqueList.retainAll()" has quadratic complexity.

The patch iterates over "coll" and calls "contains()" on "set", which
we know is fast, because "set" is a Set. For a more detailed
discussion of the patch and the problem, see the current
implementation of "ListOrderedSet.retainAll()", the discussion for
COLLECTIONS-426, and the patch for COLLECTIONS-426.

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm if the patch is correct?
5 years, 8 weeks ago 255281 No Perforce job exists for this issue. 2 84082 0|i0eqnz:
Commons Collections COLLECTIONS-424

Surprising exception by CompositeSet in a situation where CompositeCollection works fine

Bug Closed Major Fixed Unassigned Michael Pradel Michael Pradel 23/Jul/12 09:07   09/Nov/14 14:31 17/Mar/13 10:03 3.2.1 4.0-alpha1, 4.0 Set   0 3   All environments We have a method that uses a CompositeCollection. Here's a simplified version of it:

void m(CompositeCollection coll) {
coll.addComposited(new TreeBag());
}

It works fine when the argument is a CompositeCollection, but it throws an exception when the argument is a CompositeSet. E.g.:

m(new CompositeCollection()); // OK
m(new CompositeSet()); // IllegalArgumentException

Although the exception is documented in CompositeSet, this behavior is very surprising. Is there a way to have m() accept CompositeCollections without running into this exception? The only solution that comes to my mind is to dynamically check the type of 'coll' in m(), but this is a rather nasty work-around.


A better solution may be to make the genericity of CompositeCollection explicit by adding a type parameter:

class CompositeCollection<T extends Collection> {
void addComposited(T c) { /* .. */ }
}

class CompositeSet extends CompositeCollection<Set> {
@Override void addComposited(Set c) { /* .. */ }
}

This way, users of CompositeCollection must choose the kind of collections that can be composed and will not encounter surprises, such as the above.
7 years, 1 week, 2 days ago 244856 No Perforce job exists for this issue. 2 32006 0|i05uav:
Commons Collections COLLECTIONS-423

FastArrayList.toString() fails to check for reference to itself

Bug Closed Major Won't Fix Unassigned Michael Pradel Michael Pradel 23/Jul/12 09:05   27/Nov/15 21:47 26/Aug/12 21:06 3.2.1   List   0 1   All environments FastArrayList.toString() throws a StackOverflowError when the list contains itself, because toString() is called recursively. In contrast, ArrayList checks for this case and deals with it appropriately. E.g.:

ArrayList l = new FastArrayList();
l.add(l);
l.toString(); // StackOverflowError

But:

ArrayList l = new ArrayList();
l.add(l);
l.toString(); // OK

To be compatible with its superclass, FastArrayList should also consider this special case.
7 years, 34 weeks, 6 days ago 255282 No Perforce job exists for this issue. 0 84083 0|i0eqo7:
Commons Collections COLLECTIONS-418

ListUtils.retainAll() is very slow

Bug Closed Major Won't Fix Unassigned Adrian Nistor Adrian Nistor 29/Jun/12 22:16   27/Nov/15 21:47 26/Aug/12 21:32 3.2.1       0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListUtils.retainAll(). It
appears in version 3.2.1 and also in revision 1355448. I attached a
test that exposes this problem and a one-line patch that fixes it. On
my machine, for this test, the patch provides a 238X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5485

The output for the patched version is:
Time is 23

As the patch shows, the problem is that
"ListUtils.retainAll(Collection<E> collection, Collection<?> retain)"
performs "retain.contains(obj)" for each element in "collection",
which can be very expensive if "retain.contains(obj)" is expensive,
e.g., when "retain" is a list.

The one-line patch I attached puts the elements of "retain" in a
HashSet (which has very fast "contains()"), if "retain" is not already
a set:

"if (!(retain instanceof java.util.Set<?>)) retain = new HashSet<Object>(retain);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian
7 years, 30 weeks, 2 days ago 255284 No Perforce job exists for this issue. 2 84085 0|i0eqon:
Commons Collections COLLECTIONS-417

AbstractLinkedList.retainAll() is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 29/Jun/12 22:01   09/Nov/14 14:31 20/Sep/12 18:07 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in
AbstractLinkedList.retainAll(). It appears in version 3.2.1 and also
in revision 1355448. I attached a test that exposes this problem and
a one-line patch that fixes it. On my machine, for this test, the
patch provides a 158X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5531

The output for the patched version is:
Time is 35

As the patch shows, the problem is that
"AbstractLinkedList.retainAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the AbstractLinkedList,
which can be very expensive if "coll.contains()" is expensive, e.g.,
when "coll" is a list.

The one-line patch I attached puts the elements of "coll" in a HashSet
(which has very fast "contains()"), if "coll" is not already a set:

"if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian
7 years, 26 weeks, 5 days ago 244858 No Perforce job exists for this issue. 3 32008 0|i05ubb:
Commons Collections COLLECTIONS-415

AbstractLinkedList.removeAll() is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 29/Jun/12 21:02   09/Nov/14 14:31 20/Sep/12 18:08 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in
AbstractLinkedList.removeAll(). It appears in version 3.2.1 and also
in revision 1355448. I attached a test that exposes this problem and
a one-line patch that fixes it. On my machine, for this test, the
patch provides a 226X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5655

The output for the patched version is:
Time is 25

As the patch shows, the problem is that
"AbstractLinkedList.removeAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the AbstractLinkedList,
which can be very expensive if "coll.contains()" is expensive, e.g.,
when "coll" is a list.

The one-line patch I attached puts the elements of "coll" in a HashSet
(which has very fast "contains()"), if "coll" is not already a set:

"if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian
7 years, 26 weeks, 5 days ago 244857 No Perforce job exists for this issue. 3 32007 0|i05ub3:
Commons Collections COLLECTIONS-416

ListUtils.removeAll() is very slow

Bug Closed Major Won't Fix Unassigned Adrian Nistor Adrian Nistor 29/Jun/12 21:09   27/Nov/15 21:47 25/Jul/12 21:40 3.2.1       0 1   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListUtils.removeAll(). It
appears in version 3.2.1 and also in revision 1355448. I attached a
test that exposes this problem and a one-line patch that fixes it. On
my machine, for this test, the patch provides a 217X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5430

The output for the patched version is:
Time is 25

As the patch shows, the problem is that
"ListUtils.removeAll(Collection<E> collection, Collection<?> remove)"
performs "remove.contains(obj)" for each element in "collection",
which can be very expensive if "remove.contains(obj)" is expensive,
e.g., when "remove" is a list.

The one-line patch I attached puts the elements of "remove" in a
HashSet (which has very fast "contains()"), if "remove" is not already
a set:

"if (!(remove instanceof java.util.Set<?>)) remove = new HashSet<Object>(remove);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian
7 years, 34 weeks, 6 days ago 292943 No Perforce job exists for this issue. 2 164345 0|i0shpb:
Commons Collections COLLECTIONS-413

Performance problem in DualHashBidiMap

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 21/Jun/12 18:38   09/Nov/14 14:31 23/Jun/12 12:06 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in DualHashBidiMap. It
appears in version 3.2.1 and also in revision 1352574 (21 June 2012).
I attached a test that exposes this problem and a patch that fixes it.
On my machine, for this test, the patch provides a 173X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5029

The output for the patched version is:
Time is 29

The attached test shows that, for a "DualHashBidiMap bidi" object, the
following operation is very slow:

bidi.entrySet().removeAll(toRemove);

DualHashBidiMap.entrySet() returns a
"DualHashBidiMap.EntrySet" object, which inherits
removeAll(Collection<?> coll) from "DualHashBidiMap.View".

As the patch shows, the problem is that
"DualHashBidiMap.View.removeAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the View.
"coll.contains(it.next())" can be very slow, e.g., if "coll" is a
list.

The patch avoids this cost by using remove(Object obj) (defined in
"EntrySet<K, V>", "KeySet<K>", and "Values<V>"), which is fast because
it uses only operations on sets.

Is this a bug, or am I misunderstanding something? If so, can you
please confirm that the patch is correct?

Thanks,

Adrian


7 years, 39 weeks, 3 days ago 292945 No Perforce job exists for this issue. 2 164347 0|i0shpr:
Commons Collections COLLECTIONS-420

CompositeCollection.containsAll() is very slow

Bug Closed Major Won't Fix Unassigned Adrian Nistor Adrian Nistor 30/Jun/12 01:05   27/Nov/15 21:47 26/Aug/12 21:25 3.2.1       0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in
CompositeCollection.containsAll(). It appears in version 3.2.1 and
also in revision 1355448. I attached a test that exposes this problem
and a patch that fixes it. On my machine, for this test, the patch
provides a 167X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 9192

The output for the patched version is:
Time is 54

The problem is that
"CompositeCollection.containsAll(Collection<?> coll)" performs
"contains(item)" for each item in "coll", and "contains(item)"
searches "item" in all collections in CompositeCollection. This can
be very slow if the collections in CompositeCollection have slow
"contains()", e.g., when these collections are lists.

The patch I attached puts the elements in each collection of
CompositeCollection in a HashSet (which has very fast "contains()") if
that collection is not already a set. For efficiency, putting
elements in several HashSet objects is performed lazily in the patch.

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian
7 years, 30 weeks, 2 days ago 255283 No Perforce job exists for this issue. 2 84084 0|i0eqof:
Commons Collections COLLECTIONS-409

ListOrderedSet.addAll() is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 19/Jun/12 16:00   09/Nov/14 14:31 19/Jun/12 19:52 3.2.1 4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in ListOrderedSet.addAll().
It appears in version 3.2.1 and also in revision 1351465 (18 Jun
2012). I have attached a test that exposes this problem and a
three-line patch that fixes it. On my machine, for this test, the
patch provides a 79X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 1837

The output for the patched version is:
Time is 23

As the patch shows, the problem is that
ListOrderedSet.addAll(int index, Collection<? extends E> coll)
performs:
"setOrder.add(index++, e)" for each element in "coll". This is very
expensive, because "setOrder" is an ArrayList, and inserting an
element in the middle of an ArrayList shifts all the elements to the
right.

The patched version avoids this cost by inserting all the elements at
once, thus performing only one insert.

Is this a bug? If so, can you please confirm that the patch is
correct?

Thanks,

Adrian
7 years, 40 weeks ago 292949 No Perforce job exists for this issue. 2 164351 0|i0shqn:
Commons Collections COLLECTIONS-524

ListOrderedSet can have duplicates

Bug Closed Major Fixed Unassigned J Goodfellow J Goodfellow 06/May/14 00:58   27/Nov/15 21:11 06/May/14 22:14 3.2.1, 4.0 4.1     0 1   tomcat 7, linux The static method, org.apache.commons.collections.set.ListOrderedSet.decorate(List list), has a comment "If the list contains duplicates, the duplicates are removed". It does not remove duplicates and will leave you in an inconsistent state if your list has duplicates. (i.e. the .size() result is smaller than the number of iterations from the iterator) 5 years, 46 weeks ago 390786 No Perforce job exists for this issue. 0 391026 0|i1vb5z:
Commons Collections COLLECTIONS-487

CollectionUtils.removeAll is not work as expected

Bug Closed Blocker Duplicate Unassigned Cooper Cooper 21/Oct/13 07:48   09/Nov/14 14:31 21/Oct/13 07:56 3.2.1 4.0 Collection, List   0 1 360 360 0% JDK 1.6 http://svn.apache.org/viewvc/commons/proper/collections/tags/COLLECTIONS_3_2_1/src/java/org/apache/commons/collections/CollectionUtils.java?revision=1211567&view=markup

Line: 1122
Problem:
The method called "removeAll", but call "retainAll" internally.
0% 0% 360 360
6 years, 22 weeks, 1 day ago 354363 No Perforce job exists for this issue. 0 354653 0|i1p3cf:
Commons Collections COLLECTIONS-536

(Code style) map.size() call in MapUtils.putAll()

Bug Closed Trivial Fixed Unassigned Tagir Valeev Tagir Valeev 29/Oct/14 02:58   27/Nov/15 21:11 29/Oct/14 21:05 3.2.1, 4.0 4.1 Map   0 1   Any In class org.apache.commons.collections(4).MapUtils there's a method putAll(final Map<K, V> map, final Object[] array) which starts with
{noformat}
map.size(); // force NPE
{noformat}

Actually map.size() is not that harmless call for any map. For example, consider java.util.concurrent.ConcurrentHashMap size() implementation: depending on the circumstances it may take even more time than the rest of the putAll method (at least prior to JDK 8). Things are even worse for ConcurrentSkipListMap: its size() method iterates over all the map elements. Thus I'd suggest to replace this call with more conventional check like:
{noformat}
if(map == null) {
throw new NullPointerException();
}
{noformat}

If you still want to save bytes, you may use {{map.getClass()}}. It's final, so it will never be overridden to do something strange and it's even used by JavaC for the same purpose (to trigger NPE). For example, if you compile and disassemble this code:
{noformat}
public class Outer {
public class Inner {}
public void test(Outer n) { n.new Inner(); }
}
{noformat}
You will see a getClass() call which is used to trigger NPE.
performance 5 years, 20 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i21pc7:
Commons Collections COLLECTIONS-394

FastTreeMap is not compatible with TreeMap

Bug Closed Major Won't Fix Unassigned Michael Pradel Michael Pradel 29/Feb/12 14:49   27/Nov/15 21:47 23/Jun/12 17:14 3.2.1   Map   0 1   all FastTreeMap extends TreeMap in a way that doesn't preserve the superclass behavior. For example, the following code prints 'null', but I would expect it to print '1=1', which is what TreeMap does:

TreeMap map = new FastTreeMap();
//TreeMap map = new TreeMap();

map.put(1, "1");
map.put(3, "3");

Entry e = map.floorEntry(2);
System.out.println(e);

This behavior is surprising and can hit you every time a reference of type TreeMap refers to an instance of FastTreeMap. A subclass instance used through a superclass interface shouldn't change the visible behavior of its superclass.

The reason for this problem seems to be that FastTreeMap both extends TreeMap and delegates to a TreeMap via the 'map' field. I.e., there are two map instances for a single FastTreeMap instance.
7 years, 39 weeks, 3 days ago 229815 No Perforce job exists for this issue. 0 164361 0|i0shsv:
Commons Collections COLLECTIONS-387

CollectionUtils.removeAll does retain instead of remove

Bug Closed Major Duplicate Unassigned Taras Pushyk Taras Pushyk 27/Dec/11 12:34   28/Feb/13 20:02 27/Dec/11 12:35 3.2.1 4.0 Collection   0 0   org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection) method calls org.apache.commons.collections.ListUtils.retainAll(Collection, Collection) instead of org.apache.commons.collections.ListUtils.removeAll(Collection, Collection). bug, removeAll
8 years, 13 weeks ago 222100 No Perforce job exists for this issue. 0 164368 0|i0shuf:
Commons Collections COLLECTIONS-386

CollectionUtils.removeAll(Collection, Collection) has an CopyPaste-Failure

Bug Closed Critical Duplicate Joerg Schaible Steininger Thomas Steininger Thomas 03/Nov/11 14:07   03/Nov/11 16:19 03/Nov/11 16:19 3.2.1 4.0, Nightly Builds     0 1   commons-collections-3.2.1.jar public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
8 years, 20 weeks, 5 days ago 215909 No Perforce job exists for this issue. 0 164369 0|i0shun:
Commons Collections COLLECTIONS-690

Source code compilation error

Bug Resolved Major Won't Fix Unassigned Jayanth G H Jayanth G H 20/Jul/18 05:13 18/Mar/20 02:55 20/Jul/18 08:56 20/Jul/18 08:56 3.2.2   Collection   0 1   Windows 10 
JDK 1.8
# Took source code from "https://github.com/apache/commons-collections/tree/collections-3.2.2"
# Trying to compile the code using "ant compile" in command prompt
# Got the compilation error. Error logs is attached.
1 year, 34 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807
Important
0|i3w3lj:
Commons Collections COLLECTIONS-712

ExtendedProperties.save swallows instead of throws IOException

Bug Closed Trivial Won't Fix Unassigned Philip Hodges Philip Hodges 18/Mar/19 13:39   05/Jul/19 17:23 05/Jul/19 15:31 3.2.2   Properties   0 1   commons-collections-3.2.2-src/src/java/org/apache/commons/collections/ExtendedProperties.java

/**
 * Save the properties to the given output stream.
 * ...
 * @throws IOException if an IO error occurs - no it does not.
 */
public synchronized void save(OutputStream output, String header) throws IOException {
...
PrintWriter theWrtr = new PrintWriter(output);
...
// theWrter.flush();
// missing: if (theWrtr.checkError()) throw new IOException();

Impact: caller cannot tell if the properties were completely saved, perhaps the disk filled up instead. Missing checkError is an antipattern for PrintWriter and PrintStream.
36 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z00tgo:
Commons Collections COLLECTIONS-701

StackOverflowError in SetUniqueList.add() when it receives itself

Bug Resolved Critical Fixed Unassigned Shin Hong Shin Hong 31/Oct/18 12:38   23/Nov/18 07:32 23/Nov/18 07:32 3.2.2 4.3 Collection   0 5   Hi.

We found that the following test case fails with a StackOverFlowError exception:
{code:java}
test() {       
SetUniqueList l = new SetUniqueList(new LinkedList<Object>()) ;       
l.add((Object) l) ;   
}{code}
The add() execution traps into an infinite recursion which crashes the program.

From the stack trace, we found that the infinite recursion occurs

at AbstractList.hashCode() since it invokes hashCode() of each of its elements.

 
1 year, 16 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Important
0|i3zucv:
Commons Collections COLLECTIONS-596

FileInputStream is not closed

Bug Resolved Major Won't Fix Unassigned Kaloyan Spiridonov Kaloyan Spiridonov 30/Sep/16 13:36   24/May/17 08:34 24/May/17 08:34 3.2.2       0 2   In ExtendedProperties class on 602 line the function load is called with input stream. I do not see anywhere stream to be closed. Is there any reason for that?
2 years, 42 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i34avr:
Commons Collections COLLECTIONS-585

When use commons collection 3.2.2, show "JavaSE not found"

Bug Open Minor Unresolved Unassigned neal zhang11 neal zhang11 29/Jan/16 02:53 18/Mar/20 02:08 04/Nov/19 03:07   3.2.2   Collection   0 3   jdk1.7 commons-collections 3.2.2 Hi all, when i use commons-collections 3.2.2, and build my rcp application. it always show this error:
[java] [eclipse.generateFeature] Some inter-plug-in dependencies have not been satisfied.
[java] [eclipse.generateFeature] Bundle org.apache.commons.collections:
[java] [eclipse.generateFeature] Host plug-in JavaSE_0.0.0 has not been found.

but for commons-collections 3.2.1.every thing is fine.
and compared the 3.2.2 and 3.2.1
Mainfest.mf file add this:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.3))"
if remove it, i can build my application.
i use jdk1.7 in my local(i also tested jdk1.8, same problem)
so i don't understand why show this problem.
i am new guy for this, if misunderstand this, sorry
19 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2s4lr:
Commons Collections COLLECTIONS-582

Maven repository metadata of Commons Collections in bad condition

Bug Closed Major Won't Fix Unassigned Alexander Veit Alexander Veit 18/Nov/15 08:00   27/Nov/15 21:47 18/Nov/15 08:05 3.2.2   Core   0 2   The metadata located at

https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml

are in a bad condition.

It states that latest version and release version is 20040616. Moreover, the list of versions does not reflect the actual release order.

This makes it difficult to automatically check for new versions in our QA processes.
4 years, 17 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2okcf:
Commons Collections COLLECTIONS-482

Transformed* classes require double the number of generic qualifiers

Bug Closed Major Duplicate Unassigned Hollis Waite Hollis Waite 10/Sep/13 18:16 18/Mar/20 02:58 27/Nov/15 21:47 10/Sep/13 19:55 4.0-alpha1   Bag, Collection, List, Map, Set   0 1   Transformed* classes currently have the same number of generic qualifiers as their parent interfaces (e.g. one for TransformedList and two for TransformedMap). In order to handle transformations between different types, transforming collections should specify both input and output classes.
6 years, 28 weeks ago 347799 No Perforce job exists for this issue. 0 348098 0|i1nz13:
Commons Collections COLLECTIONS-475

Wrong timeout handling in expiration policies of PassiveExpiringMap

Bug Closed Minor Fixed Unassigned Thomas Neidhart Thomas Neidhart 02/Jul/13 21:04   09/Nov/14 14:31 14/Jul/13 19:09 4.0-alpha1 4.0     0 0   The timeunit parameter in the ctor of ConstantTimeToLiveExpirationPolicy is not used.

Additionally, the validateAndConvertToMillis method is wrong, it should be changed like this:

{noformat}
private static long validateAndConvertToMillis(final long timeToLive,
final TimeUnit timeUnit) {
if (timeUnit == null) {
throw new IllegalArgumentException("Time unit must not be null");
}
return TimeUnit.MILLISECONDS.convert(timeToLive, timeUnit);
}
{noformat}
6 years, 36 weeks, 2 days ago 336120 No Perforce job exists for this issue. 0 336444 0|i1lz7z:
Commons Collections COLLECTIONS-498

CollectionBag should respect removeAll / retainAll contract of decorated bags

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 11/Nov/13 19:46   09/Nov/14 14:31 11/Nov/13 20:29 4.0-alpha1 4.0     0 0   In case the decorated collection does not support removal, i.e. throws an UnsupportedOperationException, CollectionBag does not respect this in case a null argument was specified.

To be consistent with the testing framework, CollectionBag shall delegate the call to the decorated collection in such cases.
6 years, 19 weeks, 1 day ago 358017 No Perforce job exists for this issue. 0 358307 0|i1ppuv:
Commons Collections COLLECTIONS-501

Rename MultiKeyMap.remove(K key1, K key2) to avoid clashes with newly introduced default methods in Java 8

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 17/Nov/13 16:04   09/Nov/14 14:31 17/Nov/13 18:31 4.0-alpha1 4.0     0 0   Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key1, K key2)" in our MultiKeyMap interface.

To avoid future problems rename the method (and other similar methods with more multi key arguments) to a more specific version:

* V removeMultiKey(K key1, K key2, ...)
* V removeKey(K key1, K key2, ...)
6 years, 18 weeks, 2 days ago 358997 No Perforce job exists for this issue. 0 359287 0|i1pvwf:
Commons Collections COLLECTIONS-500

Rename MultiMap.remove(K, V) to avoid clashes with newly introduced default methods in Java 8

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 17/Nov/13 16:02   09/Nov/14 14:31 17/Nov/13 17:10 4.0-alpha1 4.0     0 0   Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key, V value)" in our MultiMap interface.

To avoid future problems rename the method to a more specific version and change the return type to be more logical. Brief discussion on the ml favored either:

* boolean removeMapping(K key, V value)
* boolean removeValue(K key, V value)
6 years, 18 weeks, 2 days ago 358996 No Perforce job exists for this issue. 0 359286 0|i1pvw7:
Commons Collections COLLECTIONS-496

UnmodifiableBoundedCollection does not implement Unmodifiable marker interface

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 11/Nov/13 16:42   09/Nov/14 14:31 11/Nov/13 16:47 4.0-alpha1 4.0     0 0   The UnmodifiableBoundedCollection does not implement the Unmodifiable interface. 6 years, 19 weeks, 1 day ago 357969 No Perforce job exists for this issue. 0 358259 0|i1ppk7:
Commons Collections COLLECTIONS-495

UnmodifiableTrie should not decorate an already unmodifiable Trie

Bug Closed Minor Fixed Unassigned Thomas Neidhart Thomas Neidhart 11/Nov/13 16:25   09/Nov/14 14:31 11/Nov/13 16:30 4.0-alpha1 4.0     0 0   An already unmodifiable trie was decorated again.
To be consistent with the other Unmodifiable wrappers, in this case the object itself shall be returned.

Also the return type shall be changed to Trie.
6 years, 19 weeks, 1 day ago 357967 No Perforce job exists for this issue. 0 358257 0|i1ppjr:
Commons Collections COLLECTIONS-597

Correction of Javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure

Bug Resolved Trivial Fixed Gary D. Gregory Enrique Enrique 20/Oct/16 13:47 18/Mar/20 02:58 21/Oct/16 05:53 21/Oct/16 05:53 4.0, 4.1 4.2 Functor   0 2 300 300 0% Correct the javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing:
CollctionUtils.forAllDo(strList, writer);
by:
CollectionUtils.forAllDo(strList, writer);
0% 0% 300 300 documentation 3 years, 21 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i355kf:
Commons Collections COLLECTIONS-553

TransformedMultiValuedMap.equals() fails when comparing the value with itself

Bug Closed Major Fixed Unassigned M Kim M Kim 16/Feb/15 16:09   27/Nov/15 21:11 07/Apr/15 11:41 4.0 4.1 Map   0 1   TransformedMultiValuedMap.equals() does not return true when comparing a value of a Collection key with itself. Is it allowed to put Collection as a key in TransformedMultiValuedMap at all? If not, I think it should be specified in the document. Or, equals() should be fixed accordingly.

Reproduce step
{code:title=Test.java|borderStyle=solid}
public void test()
{
TransformedMultiValuedMap map = TransformedMultiValuedMap.transformingMap((MultiValuedMap)new MultiValuedHashMap(),TransformerUtils.stringValueTransformer(), TransformerUtils.stringValueTransformer());

MultiValuedHashMap helperMap = new MultiValuedHashMap();
helperMap.put("KEY", "Value");
Collection key = helperMap.keySet();
map.put(key, "Hi");
Collection value = map.get(key);
assertTrue("Contract failed: value.equals(value)", value.equals(value));
}
{code}
4 years, 50 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i25onj:
Commons Collections COLLECTIONS-545

Undocumented performance issue in the removeAll method in CollectionUtils

Bug Closed Trivial Fixed Unassigned Oswaldo Olivo Oswaldo Olivo 12/Jan/15 06:04   27/Nov/15 21:11 23/Jan/15 09:34 4.0 4.1 Collection   0 1   Ubuntu 14.04 This bug is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-544

The method removeAll in CollectionUtils is inefficient when the second parameter collection has a slow containment method.

The following is the current implementation with its documentation:
============================
/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param <E> the type of object the {@link Collection} contains
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since 4.0 (method existed in 3.2 but was completely broken)
*/
public static <E> Collection<E> removeAll(final Collection<E> collection, final Collection<?> remove) {
return ListUtils.removeAll(collection, remove);
}


=======================================

We can notice the inefficiency by looking at the removeAll method in ListUtils.
The removeAll method from ListUtils is implemented and documented as follows:

=======================================

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a list containing all the elements in <code>collection</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* <code>collection</code> and thus cannot call <code>collection.removeAll(remove);</code>.
* <p>
* This implementation iterates over <code>collection</code>, checking each element in
* turn to see if it's contained in <code>remove</code>. If it's not contained, it's added
* to the returned list. As a consequence, it is advised to use a collection type for
* <code>remove</code> that provides a fast (e.g. O(1)) implementation of
* {@link Collection#contains(Object)}.
*
* @param <E> the element type
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>List</code> containing all the elements of <code>c</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <E> List<E> removeAll(final Collection<E> collection, final Collection<?> remove) {
final List<E> list = new ArrayList<E>();
for (final E obj : collection) {
if (!remove.contains(obj)) {
list.add(obj);
}
}
return list;
}

=======================================

In the case of ListUtils:removeAll, the inefficiency is properly documented.

Perhaps the disclaimer about potential inefficiencies depending on the type
of the parameter collection in ListUtils:removeAll should also be included in CollectionUtils:removeAll.
Collections, documentaion, performance 5 years, 8 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i248xr:
Commons Collections COLLECTIONS-548

Performance issue in CompositeCollection::retainAll

Bug Closed Minor Won't Fix Unassigned Oswaldo Olivo Oswaldo Olivo 21/Jan/15 21:50   27/Nov/15 21:47 24/Jan/15 12:59 4.0   Collection   0 1   Ubuntu 14.04 There seems to be a performance problem with the function retainAll of
CompositeCollection. This is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-534 .

The following is the code of the function:

{code}

/**
* Retains all the elements in the specified collection in this composite collection,
* removing all others.
* <p>
* This implementation calls <code>retainAll()</code> on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection<?> coll) {
boolean changed = false;
for (final Collection<E> item : all) {
changed |= item.retainAll(coll);
}
return changed;
}


{code}

The performance problem occurs when the underlying collections in the current collection have a slow retainAll method. Whenever we're relying on Collection::retainAll, slow cases tend to occur when the parameter collection has a slow contains method.

The following test harness shows the performance degradation between
using a list and using a set as a parameter, across different collection sizes.

{code}
public static void compositeCollectionRetainAllTest(boolean original) {

int N=500000;

ArrayList<Integer> firstArrayList=new ArrayList<Integer>();
ArrayList<Integer> secondArrayList=new ArrayList<Integer>();

for(int i=0;i<N;++i) {

firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));

}
CompositeCollection col = new CompositeCollection(firstArrayList);

col.retainAll(original ? secondArrayList : (new HashSet<Integer>(secondArrayList)));


}


{code}

In the following table "Original" corresponds to the time taken by
the existing implementation of CompositeCollection::retainAll, "Repaired" to the time taken by the function invoked with the parameter converted into a set, and "Speed-up" to the speed-up obtained after the repair.

N Original(s) Repaired(s) Speed-up(X)

10 1.04 1.04 1.00
100 1.04 1.05 0.99
1000 1.06 1.06 1.00
10000 1.12 1.10 1.01
100000 9.34 1.15 8.12
500000 > 300 1.29 > 232.55


If it's unacceptable to convert the parameter into a set before calling
retainsAll, a solution would be to include a warning to the user in the documentation that the parameter should have a fast contains method when possible.
performance
5 years, 8 weeks, 3 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i24n0n:
Commons Collections COLLECTIONS-547

Performance issue in SetUtils::isEqualSet

Bug Closed Minor Not A Problem Unassigned Oswaldo Olivo Oswaldo Olivo 21/Jan/15 21:10   27/Nov/15 21:47 22/Jan/15 09:18 4.0   Set   0 1   Ubuntu 14.04 There seems to be a performance problem with the function isEqualSet of
SetUtils when the first parameter is of a collection type that has a slow containsAll/contains method.

The following is the code of the function:

{code}
/**
* Tests two sets for equality as per the <code>equals()</code> contract
* in {@link java.util.Set#equals(java.lang.Object)}.
* <p>
* This method is useful for implementing <code>Set</code> when you cannot
* extend AbstractSet. The method takes Collection instances to enable other
* collection types to use the Set implementation algorithm.
* <p>
* The relevant text (slightly paraphrased as this is a static method) is:
* <blockquote>
* <p>Two sets are considered equal if they have
* the same size, and every member of the first set is contained in
* the second. This ensures that the <tt>equals</tt> method works
* properly across different implementations of the <tt>Set</tt>
* interface.</p>
*
* <p>
* This implementation first checks if the two sets are the same object:
* if so it returns <tt>true</tt>. Then, it checks if the two sets are
* identical in size; if not, it returns false. If so, it returns
* <tt>a.containsAll((Collection) b)</tt>.</p>
* </blockquote>
*
* @see java.util.Set
* @param set1 the first set, may be null
* @param set2 the second set, may be null
* @return whether the sets are equal by value comparison
*/
public static boolean isEqualSet(final Collection<?> set1, final Collection<?> set2) {
if (set1 == set2) {
return true;
}
if (set1 == null || set2 == null || set1.size() != set2.size()) {
return false;
}

return set1.containsAll(set2);
}

{code}

The problem is that in the last return statement, the function relies on the
containsAll method of the class of the set1, which can be any type of collection.

The following test harness shows the performance degradation between
using a list and using a set as a first parameter, across different collection sizes.

{code}
public static void setUtilsisEqualSetTest(boolean original) {

int N=500000;
ArrayList<Integer> firstArrayList=new ArrayList<Integer>();
ArrayList<Integer> secondArrayList=new ArrayList<Integer>();
for(int i=0;i<N;++i) {

firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer((N-1)-i));

}

SetUtils.isEqualSet(original?firstArrayList:(new HashSet<Integer>(firstArrayList)),secondArrayList);

{code}

In the following table "Original" corresponds to the time taken by
the existing implementation of SetUtils::isEqualSet, "Repaired" to the time
taken by the function invoked with the first parameter converted into a
set, and "Speed-up" to the speed-up obtained after the repair.


N Original(s) Repaired(s) Speed-up(X)

10 1.01 1.02 0.99
100 1.02 1.02 1
1000 1.04 1.04 1
10000 1.15 1.09 1.05
100000 9.33 1.11 8.40
500000 > 300 1.26 > 238.09


One way to deal with this would be to call the CollectionUtils::containsAll method instead of Collection::containsAll, since it has a linear time implementation instead of quadratic, and can handle the types of isEqualSet.

Another solution would be to include a warning to the user in the documentation that the first parameter should have a fast containment method when possible.


perfomance
5 years, 8 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i24mx3:
Commons Collections COLLECTIONS-543

AbstractCollectionDecorator should not delegate equals and hashcode

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 07/Jan/15 22:05   27/Nov/15 21:11 12/Jan/15 15:21 4.0 4.1     0 0   In order to preserve the symmetry of equals the AbstractCollectionDecorator shall not forward calls to equals and hashcode to the decorated collection.

The test for equality usually also includes a test for the specific interface, e.g. List, which the collection decorator does not implement.

The relevant sub-classes like AbstractListDecorator can delegate the calls to safely fulfill the Collections contract.
5 years, 10 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i241uf:
Commons Collections COLLECTIONS-531

Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases

Bug Closed Minor Fixed Unassigned Dipanjan Laha Dipanjan Laha 27/May/14 10:13   27/Nov/15 21:11 29/May/14 18:34 4.0 4.1 Collection   0 1   CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined as
{code}
public static boolean isEqualCollection(final Collection<?> a, final Collection<?> b, final Equator<?> equator) {
...
}
{code}

This makes it possible to invoke it with a code like
{code}
public static class IntegerEquator implements Equator<Integer> {
public boolean equate(Integer o1, Integer o2) {
return o1.intValue() == o2.intValue();
}
public int hash(Integer o) {
return o.intValue();
}
}

@Test
public void test() {
List<Long> longList = Arrays.asList(1L, 2L);
List<Integer> intList = Arrays.asList(1, 2);
assertTrue(CollectionUtils.isEqualCollection(longList, intList, new IntegerEquator()));

}
{code}
which compiles perfectly but throws a ClassCastException as Long cannot be cast to an Integer. However, the generics should be defined such that this is stopped at compile time itself.

If we modify the method to something like
{code}
public static <E> boolean isEqualCollection(final Collection<? extends E> a, final Collection<? extends E> b, final Equator<? super E> equator) {
...
}
{code}
the above example would give a compile time error. imho we should modify this method with bounded wildcards. I don't think this change would break any existing binaries if the method is being used correctly, otherwise it is probably throwing ClassCastExceptions anyway.

Test case attached
5 years, 42 weeks, 5 days ago 394974 No Perforce job exists for this issue. 1 395109 0|i1w06v:
Commons Collections COLLECTIONS-592

Deletions/insertions get lost in the ReplacementsFinder if they're at the end of the compared sequences

Bug Open Minor Unresolved Unassigned Alexis Mestag Alexis Mestag 19/Jun/16 22:19 18/Mar/20 02:08 20/Jun/16 07:31   4.0, 4.1       0 1   In the {{sequence}} package, when comparing 2 lists with a {{SequencesComparator}} and visiting the {{EditScript}} with a {{ReplacementsFinder}}, pending deletions and insertions get lost in the {{ReplacementsFinder}} when they're at the end of the sequences.

The {{ReplacementsFinder}} stores the deletions and insertions until it encounters a {{KeepCommand}}, when it flushes the pending commands by triggering the {{handleReplacement}} method of its {{ReplacementHandler}}.

The problem is, when edit commands are at the end of the sequences, the {{ReplacementsFinder}} will never encounter a {{KeepCommand}} to flush them, so they're stuck here and will never be handed over the {{ReplacementHandler}}.

To fix this behavior in client code, one can manually call {{ReplacementsFinder.visitKeepCommand(null)}} after the {{EditScript.visit()}} call.

I patched this bug in the library by adding a {{CommandVisitor.endOfVisit}} method and calling it at the end of the {{EditScript.visit}} method, so it allows to flush the pending deletions/insertions in the {{ReplacementsFinder}} when the end of the {{EditScript}} is reached.
3 years, 39 weeks, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807
Patch
0|i2zpnr:
Commons Collections COLLECTIONS-577

PatriciaTrie bugs when only a few bits change

Bug Closed Critical Duplicate Unassigned Chris Duncan Chris Duncan 25/Sep/15 22:27   27/Nov/15 21:47 28/Sep/15 09:45 4.0 4.1 Map   0 1   I have a bug report for you, for the class AbstractPatriciaTrie.
It has to do with how you handle bits when they are very close to each other.
For example, some of your methods seem to think that if the only difference between a prefix and a longer string, is a single additional bit, then they are actually the same data. Or if the only difference is some number of zero bits, then it also thinks they are the same data.
There are also MANY situations where the prefixMap does not return all the strings that start with the prefix.

Can you also make AbstractPatriciaTrie public, and your other package level methods into protected level, that way I don't have to copy the entire class and subclasse's code out into another class just to extend it?

thank you,
Chris Duncan (github user: VEQRYN)
4 years, 25 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2ll0f:
Commons Collections COLLECTIONS-579

PassiveExpiringMap doesn't work when the key is a byte array

Bug Closed Major Invalid Unassigned Roger R Andrews Roger R Andrews 04/Nov/15 12:48   27/Nov/15 21:47 04/Nov/15 13:19 4.0   Map   0 1   GNU/Linux Ubuntu 15.10 64 bits, OpenJDK 1.8.0_65 When you put a (key,value) pair in a PassiveExpiringMap and the key is byte[] you can't retrieve it.

Code to reproduce the problem:

byte[] key = {0,0,0,1};
PassiveExpiringMap<byte[],byte[]> map = new PassiveExpiringMap<byte[],byte[]> ();
map.put(key,key);

byte[] queryKey = {0,0,0,1};
//this should be true
map.containsKey(queryKey) == false

4 years, 19 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Important
0|i2nxsf:
Commons Collections COLLECTIONS-516

NullPointerException in MapUtils.toProperties

Bug Closed Major Fixed Unassigned Cyrille Artho Cyrille Artho 10/Apr/14 04:39   27/Nov/15 21:11 19/May/14 20:38 4.0 4.1 Collection   0 1   Mac OS 10.9, Java 6 calling MapUtils.toProperties with a map having null entries results in a NullPointerException. In this case the Map has only entry <null, null>.

However, javadoc states "A null input will return an empty
properties object." so (1) this should be clarified as it would
only apply to the map reference itself, not its contents, or (2)
an empty property object should be generated for null entries in
the map as well.
5 years, 44 weeks, 1 day ago 385961 No Perforce job exists for this issue. 1 386225 0|i1uhnb:
Commons Collections COLLECTIONS-515

ClassCastException in LazySortedMap when used with equals/transformers

Bug Closed Major Invalid Unassigned Cyrille Artho Cyrille Artho 10/Apr/14 04:36   27/Nov/15 21:47 10/Apr/14 20:46 4.0   Collection, Map   0 1   Mac OS 10.9, Java 6 When LazySortedMap is used by equals, the result is
java.lang.ClassCastException: org.apache.commons.collections4.map.LazySortedMap cannot be cast to java.lang.String

This seems to be odd, as the use of the different transformations should not result in internal casting to String. See the attached unit test to reproduce.
5 years, 49 weeks, 5 days ago 385960 No Perforce job exists for this issue. 1 386224 0|i1uhn3:
Commons Collections COLLECTIONS-514

NullPointerException in MapBackedSet.mapBackedSet

Bug Closed Major Invalid Unassigned Cyrille Artho Cyrille Artho 10/Apr/14 04:31   27/Nov/15 21:47 10/Apr/14 20:59 4.0   Bag, Collection, Set   0 1   MacOS 10.9, Java 6 It seems that addAll has issues with adding a set that is backed by a singleton map with entry null -> null. However, the javadoc of the involved classes does not state that null entries are disallowed.
Either the code should allow adding a null entry to a bag, or the documentation should state that null entries are not allowed.

See the attached unit test in JUnit format to reproduce the problem.
5 years, 49 weeks, 5 days ago 385959 No Perforce job exists for this issue. 1 386223 0|i1uhmv:
Commons Collections COLLECTIONS-513

NullPointerException in SwitchTransformer.transform

Bug Closed Major Invalid Unassigned Cyrille Artho Cyrille Artho 10/Apr/14 02:00   27/Nov/15 21:47 10/Apr/14 20:28 4.0   Functor   0 1   Mac OS 10.9, Java 6 and Java 7 A relatively complex test case generated by Randoop results in a NullPointerException in SwitchTransformer.transform.

I'm not sure if this is an incorrect usage of the method, or if it is a real bug.
5 years, 49 weeks, 5 days ago 385946 No Perforce job exists for this issue. 1 386210 0|i1uhjz:
Commons Collections COLLECTIONS-512

equals/hashCode mismatch

Bug Closed Major Fixed Unassigned Cyrille Artho Cyrille Artho 10/Apr/14 01:56   27/Nov/15 21:11 02/Jan/15 13:03 4.0 4.1 Collection, Comparator   0 2   Mac OS 10.9, Java 6 and Java 7 We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs.

I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue.
5 years, 11 weeks, 4 days ago 385944 No Perforce job exists for this issue. 2 386208 0|i1uhjj:
Commons Collections COLLECTIONS-518

AbstractIterableGetMapDecorator should be abstract

Bug Reopened Minor Unresolved Unassigned Dipanjan Laha Dipanjan Laha 14/Apr/14 05:36   31/May/15 18:52   4.0 5.0 Map   0 1   AbstractIterableGetMapDecorator should be abstract, but is not 4 years, 42 weeks, 2 days ago 386509 No Perforce job exists for this issue. 1 386773 0|i1ul0n:
Commons Collections COLLECTIONS-509

Clarify javadoc of CollectionBag

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 08/Mar/14 18:45   27/Nov/15 21:11 08/Mar/14 18:47 4.0 4.1     0 0   The javadoc of CollectionBag should clarify which methods have changed wrt the original Bag interface.
6 years, 2 weeks, 3 days ago 377975 No Perforce job exists for this issue. 0 378267 0|i1t4of:
Commons Collections COLLECTIONS-507

ComparatorUtils.chainedComparator(..) should not force the objects to implement Comparable

Bug Closed Major Fixed Unassigned Gerson Gerson 12/Feb/14 20:29   27/Nov/15 21:11 12/Feb/14 21:18 4.0 4.1 Comparator   0 1   6 years, 5 weeks, 6 days ago 373338 No Perforce job exists for this issue. 0 373639 0|i1sc6n:
Commons Collections COLLECTIONS-474

Exception in ListOrderedMap#putAll if map contains null values

Bug Closed Major Fixed Unassigned Ning Chen Ning Chen 24/Jun/13 18:22 18/Mar/20 02:15 09/Nov/14 14:31 30/Jun/13 20:10 4.0 4.0-alpha1, 4.0 Map   0 1   java 1.7.0_09 Dear apache developers, thanks for the great project. Recently, I encountered an IndexOutOfBoundsException in ListOrderedMap in the latest revision (r1495998) with the crash stack trace:
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2, Size: 1
at java.util.ArrayList.add(ArrayList.java:367)
at org.apache.commons.collections4.map.ListOrderedMap.put(ListOrderedMap.java:448)
at org.apache.commons.collections4.map.ListOrderedMap.putAll(ListOrderedMap.java:246)
at Test.main(Test.java:15)

I've also attached a test case that can reproduce this crash.

I think this test case actually reveals the bug reported in COLLECTIONS-411 (https://issues.apache.org/jira/browse/COLLECTIONS-411). However, it seems that the original patch for COLLECTIONS-411 missed a corner case.

Could you please check if this is indeed a bug? Thanks!
6 years, 38 weeks, 2 days ago 334836 No Perforce job exists for this issue. 1 335160 0|i1lrbb:
Commons Collections COLLECTIONS-566

IteratorUtils.collatedIterator do not use natural ordering if no comparator was provided

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 04/Jun/15 20:19   27/Nov/15 21:11 04/Jun/15 20:36 4.0 4.1     0 0   In case a null comparator was provided natural ordering should be used, as stated in the javadoc.

In fact an exception is thrown the first time the returned iterator is used.
4 years, 41 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2fnj3:
Commons Collections COLLECTIONS-570

All decorators shall throw a NullPointerException if the decorated argument is null

Bug Closed Minor Fixed Unassigned Thomas Neidhart Thomas Neidhart 22/Jun/15 09:50   27/Nov/15 21:11 22/Jun/15 13:02 4.0 4.1     0 0   To be consistent, the constructor shall throw a NullPointerException instead of a IllegalArgumentException if the argument is null. 4 years, 39 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2gbtb:
Commons Collections COLLECTIONS-559

Objects which are not of type V can be placed in a MultiValueMap<K,V>.

Bug Closed Major Invalid Unassigned Pétur Ingi Egilsson Pétur Ingi Egilsson 01/Apr/15 19:26   01/Apr/15 19:41 01/Apr/15 19:41 4.0   KeyValue   0 1 600 600 0% java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
OS X 10.10
I declared a MultiValueMap as this:
{code}
MultiValueMap<Integer, Path> duplicates = new MultiValueMap<Integer, Path>();
{code}

Elsewhere in code I doing (by accident) something in this direction
{code}
duplicates.put(number, new LinkedList<Path>());
{code}

Exceptions were being thrown when values returned from the list could not be assigned to variables of type Path.

{code:title=org.apache.commons.collections4.map.MultiValueMap.java}
public Object put(final K key, final Object value) {
...
{code}
I propose that Object in the above decleration is changed to T.
0% 0% 600 600
4 years, 50 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i27nsv:
Commons Collections COLLECTIONS-558

ListOrderedSet#remove(int) should return E instead of Object

Bug Closed Major Fixed Unassigned Felix Rabe Felix Rabe 25/Mar/15 14:46   27/Nov/15 21:11 25/Mar/15 16:03 4.0 4.1 Set   0 1   Since {{List#remove(int)}} returns {{E}} the implementation in {{ListOrderedSet}} should also return {{E}}.

Minimal example that fails to compile:
{code:java}
ListOrderedSet<String> los = new ListOrderedSet<String>();
los.add("foo");
String s = los.remove(0);
{code}
4 years, 51 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i27c8f:
Commons Collections COLLECTIONS-576

MultiKey subclassing has deserialization problem since COLLECTIONS-266: either declare protected readResolve() or MultiKey must be final

Bug Closed Major Fixed Unassigned Stephan Roch Stephan Roch 03/Sep/15 08:44   27/Nov/15 21:11 28/Sep/15 08:54 4.0 4.1 KeyValue   0 1   MultiKey from collections 4 provides a transient hashCode and a *private* readResolve to resolve COLLECTIONS-266: Issue with MultiKey when serialized/deserialized via RMI.

Unfortunately the solution does not work in case of *subclassing*: readResolve in MultiKey should be declared *protected* readResolve() to be called during deserialization of the subclass. Otherwise MultiKey must be final to avoid such subclassing.

*Testcase*:
{code:java|title=MultiKeySerializationTest.java}
package de.ivu.test.common.collections4;

import static org.junit.Assert.assertEquals;

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

import org.apache.commons.collections4.keyvalue.MultiKey;
import org.junit.Test;

public class MultiKeySerializationTest {

@Test
@SuppressWarnings("unchecked")
public void testReadResolveEqualHashCode()
throws IOException, ClassNotFoundException {
class MultiKey2<A, B>
extends MultiKey {

private static final long serialVersionUID = 1928896152249821416L;

public MultiKey2(A key1, B key2) {
super(key1, key2);
}

public A getFirst() {
return (A) getKey(0);
}

public B getSecond() {
return (B) getKey(1);
}

// FIXME: MultiKey should either declare protected readResolve() or must be final.
}
MultiKey2<String, String> one = new MultiKey2<>("bla", "blub");
System.out.println(one.hashCode());
ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(byteOut);
out.writeObject(one);
out.close();
byte[] serialized = byteOut.toByteArray();
ByteArrayInputStream byteIn = new ByteArrayInputStream(serialized);
ObjectInputStream in = new ObjectInputStream(byteIn);
MultiKey2<String, String> two = (MultiKey2<String, String>) in.readObject();
System.out.println(two.hashCode());
assertEquals("hashCode must be equal - please check for protected readResolve in MultiKey*", one.hashCode(),
two.hashCode());
}
}
{code}

*Fix:*
{code:java|title=MultiKey.java}
@@ -274,7 +274,7 @@
* only stable for the same process).
* @return the instance with recalculated hash code
*/
- private Object readResolve() {
+ protected Object readResolve() {
calculateHashCode(keys);
return this;
}
{code}
4 years, 25 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2jqh3:
Commons Collections COLLECTIONS-506

Result of CollectionUtils are different between version 3.2.1 and version 4.0

Bug Closed Major Fixed Unassigned Anthony Communier Anthony Communier 22/Dec/13 19:13   27/Nov/15 21:11 31/Dec/13 16:25 4.0 4.1     0 1   CollectionUtils V3 uses equals to compute results but not CollectionUtils v4 (it seems to use ==)

The following exemple with subtract method :

List<ObjectTest> listA = new ArrayList<ObjectTest>();
List<ObjectTest> listB = new ArrayList<ObjectTest>();

listA.add(new ObjectTest("Test1"));
listA.add(new ObjectTest("Test2"));
listA.add(new ObjectTest("Test3"));

listB.add(new ObjectTest("Test1"));
listB.add(new ObjectTest("Test2"));


Collection<?> res1 = org.apache.commons.collections.CollectionUtils.subtract(listA, listB);
System.out.println("Res1 size = " +res1.size());
Collection<?> res2 = org.apache.commons.collections4.CollectionUtils.subtract(listA, listB);
System.out.println("Res2 size = " +res2.size());


Produces this :
Res1 size = 1
Res2 size = 3

The new behaviour is not useful. It would be better to have the V3 behaviour

6 years, 11 weeks, 5 days ago 365027 No Perforce job exists for this issue. 1 365335 0|i1qx3b:
Commons Collections COLLECTIONS-504

CompositeMap should support compositing of maps of derived types

Bug Closed Minor Invalid Unassigned Peter Cooper Jr. Peter Cooper Jr. 03/Dec/13 20:33   04/Dec/13 15:32 04/Dec/13 12:56 4.0   Map   0 1   I'm attempting to composite two maps, one of which is a {{Map<String, String>}} and the other of which is a {{Map<String, Object>}}. I would have expected that I could composite them into a {{CompositeMap<String, Object>}}, but the constructors of CompositeMap expect all of the maps being composited to have exactly the same type arguments.

That is, I think the constructors should take arguments of {{Map<? extends K, ? extends V>}} instead of what they currently have of {{Map<K, V>}}, much like most collection methods, since there shouldn't be a problem accepting type arguments that are subtypes of the composite map types.

Thanks!
6 years, 15 weeks, 6 days ago 361767 No Perforce job exists for this issue. 0 362064 0|i1qczz:
Commons Collections COLLECTIONS-526

PatriciaTrie

Bug Closed Critical Duplicate Unassigned zigler zhang zigler zhang 08/May/14 04:38   08/May/14 06:04 08/May/14 06:04 4.0   Collection   0 1   android the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0;
some unittest codes as below:

PatriciaTrie<String> aTree =
new PatriciaTrie<String> ();
aTree.put("点评", "测试");
aTree.put("书评", "测试");
assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass
assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass
assertFalse(aTree.prefixMap("点").isEmpty()); //fail
assertEquals(1, aTree.prefixMap("点").size()); //fail
assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail
assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail
assertEquals(1, aTree.prefixMap("点评").values().size()); //fail
5 years, 45 weeks, 5 days ago 391330 No Perforce job exists for this issue. 0 391550 0|i1vedz:
Commons Collections COLLECTIONS-525

PatriciaTrie

Bug Closed Critical Fixed Unassigned zigler zhang zigler zhang 08/May/14 04:38   27/Nov/15 21:11 01/Jan/15 21:11 4.0 4.1 Collection   0 1   android the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0;
some unittest codes as below:

PatriciaTrie<String> aTree =
new PatriciaTrie<String> ();
aTree.put("点评", "测试");
aTree.put("书评", "测试");
assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass
assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass
assertFalse(aTree.prefixMap("点").isEmpty()); //fail
assertEquals(1, aTree.prefixMap("点").size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点评").values().size()); //fail actural 0
5 years, 11 weeks, 5 days ago 391329 No Perforce job exists for this issue. 1 391549 0|i1vedr:
Commons Collections COLLECTIONS-537

PredicateUtils (all|any)Predicate type misbehaviour Array vs. Collection

Bug Closed Major Fixed Unassigned Frank Jakop Frank Jakop 13/Nov/14 12:47   27/Nov/15 21:11 30/Dec/14 18:25 4.0 4.1 Functor   0 1   Migrating from collections-generic to collections4 we encountered a type problem with PredicateUtils. When you look at the method anyPredicate(), the signature with array is typed with "Predicate<? super T>" whereas the signature with Collection is typed "? extends Predicate<T>", so the both methods are not equivalent.
We think both methods should have the same types, so it would not break compatibility with a lot of legacy code.
5 years, 12 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i22bvr:
Commons Collections COLLECTIONS-534

Performance bug in CollectionBag::retainAll

Bug Closed Major Fixed Unassigned Oswaldo Olivo Oswaldo Olivo 15/Oct/14 21:01   27/Nov/15 21:11 19/Oct/14 12:44 4.0 4.1 Bag, Collection   0 1   Ubuntu 12.04 Hi,
There seems to be a performance bug in the method retainAll in the CollectionBag class.
The problem is that the code is checking containment over the parameter collection, which could be expensive for some types of collections like ArrayLists.
One solution could be to convert the Collection into a HashSet and check containment in the HashSet.
If this is done, then running retainAll on a 1,000,000 collection would take less than 2 seconds instead of 27 mins, according to my experiments.

____________________________________________
Here's a function to expose the bug:

public static void collectionBagRetainAllTest() {

ArrayList<Integer> coll=new ArrayList<Integer>();
for(int i=0;i<=1000000;++i)
coll.add(new Integer(i));

TreeBag<Integer> treeBag=new TreeBag<Integer>(coll);

CollectionBag<Integer> bag = new CollectionBag<Integer>(treeBag);

bag.retainAll(coll);
}
_____________________________________

Here's a proposed patch:

public boolean retainAll(final Collection<?> coll) {
if (coll != null) {
boolean modified = false;
final Iterator<E> e = iterator();
HashSet<Object> set=new HashSet<Object>(coll);
while (e.hasNext()) {
if (!set.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
} else {
// let the decorated bag handle the case of null argument
return decorated().retainAll(null);
}
}
_____________________________________
perfomance 5 years, 22 weeks, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i217vb:
Commons Collections COLLECTIONS-391

Inconsistent Javadoc comment and code for toProperties(final Map<K, V>) in org.apache.commons.collections.MapUtils

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 08/Jan/12 08:38 18/Mar/20 03:00 09/Nov/14 14:31 09/Apr/12 18:03 4.0, 4.x 4.0-alpha1, 4.0 Collection   0 0 120 120 0% Platform Indepedent The Javadoc comment below states that the parameter map "..., may not be null":
/**
..
* @param map the map to convert to a Properties object, may not be null
* @return the properties object
*/
public static <K, V> Properties toProperties(final Map<K, V> map) {
Properties answer = new Properties();
if (map != null) {
...
}
return answer;
}
However, the method return normally without throwing any exception when called with null.

Suggested Fixes:
1. Change "@param map the map to convert to a Properties object, may not be null" to "@param map the map to convert to a Properties object, may be null"
or
2. Remove "may not be null" from @param.
0% 0% 120 120 javadoc, null 7 years, 50 weeks, 1 day ago 223174 No Perforce job exists for this issue. 0 164364 0|i0shtj:
Commons Collections COLLECTIONS-390

Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils

Bug Closed Major Duplicate Unassigned SHIN HWEI TAN SHIN HWEI TAN 08/Jan/12 08:31   24/Jun/13 19:34 08/Jan/12 08:32 4.0   Buffer   0 0 120 120 0% Platform Independent The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
....
* @param map the map to use to transform the objects
* @return the transformer
* @throws IllegalArgumentException if the map is null
*/
public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) {
return MapTransformer.mapTransformer(map);
}
However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null".
or
2. Remove the entire "throws IllegalArgumentException if the map is null".
0% 0% 120 120
8 years, 11 weeks, 2 days ago 223173 No Perforce job exists for this issue. 0 164365 0|i0shtr:
Commons Collections COLLECTIONS-389

Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 08/Jan/12 08:31   09/Nov/14 14:31 09/Apr/12 17:21 4.0, 4.x 4.0-alpha1, 4.0 Collection   0 0 120 120 0% Platform Independent The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
....
* @param map the map to use to transform the objects
* @return the transformer
* @throws IllegalArgumentException if the map is null
*/
public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) {
return MapTransformer.mapTransformer(map);
}
However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null".
or
2. Remove the entire "throws IllegalArgumentException if the map is null".
0% 0% 120 120 javadoc, null 7 years, 50 weeks, 1 day ago 223172 No Perforce job exists for this issue. 0 164366 0|i0shtz:
Commons Collections COLLECTIONS-388

Inconsistent Javadoc comment and code for prototypeFactory(T) in org.apache.commons.collections.FactoryUtils

Bug Closed Major Fixed Unassigned SHIN HWEI TAN SHIN HWEI TAN 08/Jan/12 08:29   09/Nov/14 14:31 09/Apr/12 17:16 4.0, 4.x 4.0-alpha1, 4.0 Collection   0 0 120 120 0% Platform independent The Javadoc comment below states that the method "throws IllegalArgumentException if the prototype is null":
/**
..
* @param prototype the object to clone each time in the factory
* @return the <code>prototype</code> factory
* @throws IllegalArgumentException if the prototype is null
* @throws IllegalArgumentException if the prototype cannot be cloned
*/
public static <T> Factory<T> prototypeFactory(T prototype) {
return PrototypeFactory.<T>prototypeFactory(prototype);
}

However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the prototype is null" and "@return" to "@return NULL_INSTANCE if the prototype is null".
or
2. Remove the entire "throws IllegalArgumentException if the prototype is null".
0% 0% 120 120 javadoc, null 7 years, 50 weeks, 1 day ago 223171 No Perforce job exists for this issue. 0 164367 0|i0shu7:
Commons Collections COLLECTIONS-604

More uniform safe-null methods in CollectionUtils

Bug Open Minor Unresolved Bruno P. Kinoshita Bruno P. Kinoshita Bruno P. Kinoshita 26/May/17 12:41   12/Nov/19 08:27   4.1   Collection   1 4   Currently, there are 65 public methods in `CollectionUtils`. And 53 without the deprecated ones. Out of these, 24 handle `null` arguments. The remaining methods throw a `NullPointerException` (NPE) at some part of its code.

The methods that handle nulls, throw NPE, or return empty columns, boolean values, or just doesn't do anything.

As a user of the API, I would expect a more uniform behaviour across the methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods.

`removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if either parameter is `null`. However, they never check if the values are null, and instead allow the code to run until a NPE is thrown.

And the following code shows that `isEmpty` and `isFull` behave differently too.

{code:java}
Collection<String> c = null;
System.out.println(CollectionUtils.isEmpty(c)); // return true
System.out.println(CollectionUtils.isFull(c)); // throws a NPE
{code}

If I don't have to worry about `null`s with `#isEmpty`, I would expect the same from its related-method `#isFull`.

What would be a good approach for it? Define a behaviour to all methods? Or leave as is, but add more documentation?

There are a few methods that can easily be updated to check for `null` values. Others would require a bit more thinking. An example if the method in question for COLLECTIONS-600. It checks equality of collections, and when both collections are `null`, it says that they are equals. Google Guava [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232] and [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274] do not check for null values, for what it is worth.
18 weeks ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807 0|i3fipr:
Commons Collections COLLECTIONS-709

MultiSet.Entry::getCount() isn't 0 after removing the last element

Bug Closed Minor Fixed Unassigned Robert Wertman Robert Wertman 19/Jan/19 23:30 18/Mar/20 02:59 20/Jan/19 17:41 20/Jan/19 15:06 4.1, 4.2 4.3     0 1 0 1800   Removing the final element(s) in a MultiSet doesn't set the count on a MultiSet.Entry to zero.
{code:java}
protected int getCountAfterRemoval(MultiSet<String> multiset) {
MultiSet.Entry<String> entry = multiset.entrySet().iterator().next();
entry.getCount(); // = 2
multiset.remove(entry.getElement());
entry.getCount(); // = 1
multiset.remove(entry.getElement());
return entry.getCount(); // Still = 1, should be 0
}
{code}
100% 100% 1800 0
1 year, 8 weeks, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|yi03i8:
Commons Collections COLLECTIONS-721

functors.InvokerTransformer backward incompatibility bug

Bug Closed Major Not A Bug Unassigned xia0c xia0c 16/Jun/19 21:48 18/Mar/20 02:59 24/Jul/19 18:57 24/Jul/19 18:56 4.1, 4.2, 4.3       0 3   The following code snippets throw a NotSerializableException. It works well before commons-collections4 4.0 and commons-collection3. When I update it to 4.1 or newer versions, it failed.


{code:java}
@Test
public void Demo() throws IOException{
InvokerTransformer transformer = new InvokerTransformer("toString", new Class[]{}, new Object[]{});
Queue priorityQueue = new PriorityQueue(2, new TransformingComparator(transformer));
priorityQueue.add(1);

ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bout);
out.writeObject(priorityQueue);

}
{code}
performance
33 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Important
0|z03suo:
Commons Collections COLLECTIONS-722

IteratorUtils.chainedIterator() Performance Degrades

Bug Open Major Unresolved Unassigned E P E P 27/Jun/19 14:10 18/Mar/20 02:08 01/Nov/19 22:17   4.1       0 2   IteratorUtils.chainedIterator() performance degrades when chaining iterators with chained iterators.   The slowdown appears to be exponential, based upon the number of chains created.  The attached test shows the issue.  

As a reference, the same test below works as expected using Google's Guava Iterator.concat() functionality.   It is possible I am misusing the API, but the javadoc did not indicate as much.

 
19 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807 0|z045w8:
Commons Collections COLLECTIONS-673

ListUtils.partition potential integer overflow

Bug Resolved Major Fixed Unassigned John Mark John Mark 02/Feb/18 17:18   12/Jun/18 21:45 12/Jun/18 21:45 4.1 4.2 List   0 3   When calling {{ListUtils.partition()}} with a large size and large list, it is possible that an integer overflow will occur in the {{size()}} method that causes incorrect behavior. This will occur when using a size that, when added to list.size() will be larger than {{Integer.MAX_VALUE}}

Current version of Guava's {{Lists.partition()}} handle this correctly, so perhaps the code for {{ListUtils.partition()}} needs to be updated based on the latest Guava code.

A simple illustration of this:
{code}
List<String> aList = Arrays.asList("1", "2", "3", "4", "5");
List<List<String>> partitioned = ListUtils.partition(aList, Integer.MAX_VALUE);
System.out.println("Number of partitions: " + partitioned.size());
for(List<String> l : partitioned) {
System.out.println(l);
}
{code}

The above code works correctly when using Guava's {{Lists.partition()}} instead.
1 year, 40 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3ppz3:
Commons Collections COLLECTIONS-661

Intermittent test failures in Windows for HashSetValuedHashMap

Bug Resolved Major Fixed Bruno P. Kinoshita Bruno P. Kinoshita Bruno P. Kinoshita 03/Oct/17 09:54   12/Oct/17 06:31 12/Oct/17 06:31 4.1 4.2 Map   0 3   The collection HashSetValuedHashMap was added in 4.1. On Windows, test failures are not so common on JVM 8. But on Linux they are harder to happen (but still do [1], [2]).

When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But debugging on Windows with Eclipse sometimes work. Indicating it may be due to a concurrency issue, where debugging adds some extra time hiding the real issue.

I have a few ideas of where/why it could be happening, but am without a Windows box for a few days as I'm travelling. I'm reading the codebase in the meantime, but if anybody feels like working on it, feel free to chime in and suggest a fix/patch.

[1] https://travis-ci.org/apache/commons-collections/jobs/282169803
[2] http://markmail.org/thread/exwm7ggjtxzbtlkd
2 years, 22 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3kthr:
Commons Collections COLLECTIONS-660

Uncomment test in AbstractMapTest regarding LRUMap equals

Bug Resolved Minor Fixed Bruno P. Kinoshita Bruno P. Kinoshita Bruno P. Kinoshita 03/Oct/17 09:41   04/Oct/17 04:44 04/Oct/17 04:39 4.1 4.2 Map   0 1   AbstractMapTest has a [commented out|https://github.com/apache/commons-collections/blob/c8bdf60d1d0be609094e14054be0b9af0fb05521/src/test/java/org/apache/commons/collections4/map/AbstractMapTest.java#L1959] line, with a comment as follows:

{quote}his fails for LRUMap because confirmed.equals() somehow modifies map, causing concurrent modification exceptions.{quote}

While working on another test failing on Windows, I believe I've found the why for that comment, and how to fix it. Just need to finish debugging another part, and find a good Internet connection to push the fix.
2 years, 23 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Patch
0|i3ktfz:
Commons Collections COLLECTIONS-657

"union" method is resulting in data loss

Bug Closed Critical Invalid Unassigned Igor Savin Igor Savin 19/Sep/17 18:12   19/Sep/17 18:38 19/Sep/17 18:38 4.1       0 1   Create 2 instances of StringReader from strings (1 and 2), put them into a list A.
Create empty list B.
Call CollectionUtils.union(A, B);

Expected result: [1, 2]
Actual result: [1, 1].
2 years, 26 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3k8wv:
Commons Collections COLLECTIONS-656

Fix site build on Java 8

Bug Resolved Minor Fixed Bruno P. Kinoshita Bruno P. Kinoshita Bruno P. Kinoshita 12/Sep/17 10:42   13/Sep/17 07:52 13/Sep/17 07:52 4.1 4.2     0 2   Building the current master branch from git fails with

{noformat}
[INFO] Generating "FindBugs" report --- findbugs-maven-plugin:2.5.5:findbugs
[INFO] Locale is en
[INFO] Fork Value is true
[java] The following errors occurred during analysis:
[java] Error scanning java/util/Map$Entry for referenced classes
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Error scanning java/util/Comparator for referenced classes
[java] java.lang.ArrayIndexOutOfBoundsException: 1320
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for java/util/AbstractMap$SimpleEntry
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for org/apache/commons/collections4/map/StaticBucketMap$Node
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
...
{noformat}

Tested locally, and updating the commons-parent version to 42, and specifying the findbugs version from the parent property seems to fix the issue. As it could affect other parts of the build/release artefacts, I'll send a pull request to allow others to review before the parent is updated.
documentation, site
2 years, 27 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Patch
0|i3jyhr:
Commons Collections COLLECTIONS-717

ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory

Bug Open Major Unresolved Unassigned kirubakaran kirubakaran 20/May/19 13:31   05/Jul/19 15:24   4.1   Functor   0 2   WebLogic 12.2.1.3 server we have an object rejection issue with latest version of common collection for the class InstantiateFactory

we have set system property to enable unsafe serialization= true but still we have object rejection for org.apache.commons.collections.functors.InstantiateFactory.

can you please help us to resolve the issue.

Error log:

DOMAIN] > <BEA-000000> <ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory, array length: -1, nRefs: 3, depth: 2, bytes: 229, ex: n/a>

####<May 8, 2019 1:08:43,859 PM EDT> <Error> <RJVM> <nygindapnp613.us.db.com> <MS1> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <a8f22bc1-d077-4f1b-be08-7677cfc592c6-00000005> <1557335323859> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000503> <Incoming message header or abbreviation processing failed.

 java.io.InvalidClassException: filter status: REJECTED

java.io.InvalidClassException: filter status: REJECTED

        at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1255)

        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1878)

        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)

        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1560)

        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)

        at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:106)

        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2118)

        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2067)

        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)

        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)

        at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:73)

        at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:45)

        at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:324)

        at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:219)

        at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:556)

        at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:658)

        at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:397)

        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:981)

        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:917)

        at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:171)

        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)

        at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)

        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)

      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)
36 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z02uxs:
Commons Collections COLLECTIONS-554

NullPointerException in CollectionUtils.partition

Bug Closed Minor Invalid Unassigned M Kim M Kim 16/Feb/15 16:33   27/Nov/15 21:47 07/Apr/15 12:41 4.1   Collection   0 1   NullPointerException (NPE) is not suitably handled in CollectionUtils.partition. With a nullFactory, partitions.get(numberOfPredicates) can be null at line partitions.get(numberOfPredicates).add(element);.

Stack trace:
{code}
test(Test)java.lang.NullPointerException
at org.apache.commons.collections4.CollectionUtils.partition(CollectionUtils.java:1187)
at Test.test(Test.java:18)
{code}

Test case:
{code}
public void test() {
Collection input = CollectionUtils.permutations((java.util.Collection)new CircularFifoQueue(10));
Factory factory = FactoryUtils.nullFactory();
NullIsFalsePredicate p = new NullIsFalsePredicate(NullPredicate.nullPredicate());
Predicate[] predicates = p.getPredicates();
CollectionUtils.<java.lang.Object,java.util.Collection>partition((java.lang.Iterable)input, factory, predicates);
}


{code}
4 years, 50 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i25opb:
Commons Collections COLLECTIONS-555

Undefined NullPointerException in TreeBag.java

Bug Closed Minor Fixed Unassigned M Kim M Kim 16/Feb/15 17:03   27/Nov/15 21:11 17/Feb/15 22:03 4.1 4.1 Bag   0 1   In add(final E object) method of TreeBag.java, the parameter object is not null-checked in throw IlligalArgumentException statement. Thus, it crashes with an inappropriate type of exceptions when the parameter, object is null. object can be null from the argument, transform(object) in TransformedCollection.add(final E object).
I think object ==null should be added in the predicate of the throw IlligalArgumentException statement like below.

{code}
public boolean add(final E object) {
if((object==null) || (comparator() == null && !(object instanceof Comparable))) {
throw new IllegalArgumentException("Objects of type " + object.getClass() + " cannot be added to " +
"a naturally ordered TreeBag as it does not implement Comparable");
}
return super.add(object);
}
{code}
5 years, 5 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i25oqv:
Commons Collections COLLECTIONS-544

Undocumented performance issue in the retainAll method in CollectionUtils

Bug Closed Trivial Fixed Unassigned Oswaldo Olivo Oswaldo Olivo 12/Jan/15 05:55   27/Nov/15 21:11 12/Jan/15 14:06 4.1 4.1 Collection   0 2   Ubuntu 14.04 The method {{retainAll}} in {{CollectionUtils}} is inefficient when the parameter collection has a slow containment method.

The following is the current implementation with its documentation:

{noformat}
/**
* Returns a collection containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>.
*
* @param <C> the type of object the {@link Collection} contains
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>Collection</code> containing all the elements of <code>collection</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <C> Collection<C> retainAll(final Collection<C> collection, final Collection<?> retain) {
return ListUtils.retainAll(collection, retain);
}
{noformat}

We can notice the inefficiency by looking at the {{retainAll}} method in {{ListUtils}}.

The {{retainAll}} method from {{ListUtils}} is implemented and documented as follows:

{noformat}
/**
* Returns a List containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned list is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.retainAll(retain);</code>.
* <p>
* This implementation iterates over <code>collection</code>, checking each element in
* turn to see if it's contained in <code>retain</code>. If it's contained, it's added
* to the returned list. As a consequence, it is advised to use a collection type for
* <code>retain</code> that provides a fast (e.g. O(1)) implementation of
* {@link Collection#contains(Object)}.
*
* @param <E> the element type
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>List</code> containing all the elements of <code>c</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <E> List<E> retainAll(final Collection<E> collection, final Collection<?> retain) {
final List<E> list = new ArrayList<E>(Math.min(collection.size(), retain.size()));

for (final E obj : collection) {
if (retain.contains(obj)) {
list.add(obj);
}
}
return list;
}
{noformat}

In the case of {{ListUtils#retainAll}}, the inefficiency is properly documented.

Perhaps the disclaimer about potential inefficiencies depending on the type
of the parameter collection in ListUtils:retainAll should also be included in {{CollectionUtils#retainAll}}.
Collections, documentaion, performance 5 years, 10 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i248x3:
Commons Collections COLLECTIONS-595

ListOrderedSet remove()

Bug Resolved Major Not A Bug Unassigned Maleven Maleven 25/Sep/16 21:08   24/May/17 09:52 24/May/17 09:52 4.1   Set   0 3   Windows 10, Eclipse Neon Release (4.6.0) Hello Apache,

I have a class which overrides equals() and hashCode().
I create a ListOrderedSet<MyClass> mySet= new ListOrderedSet<MyClass>(), and add objects to it:
mySet.add(obj1);
etc.

Each object is initialized in the constructor with two properties first. The other properties are set afterwards, when
they are already contained in the ListOrderedSet. After I change/add some properties, then if I do mySet.contains(obj1), false is returned.
I read about that when a hashmap is created with the objects inside and then changing the objects inside it does not change
the hasmap's internal hashcode for the objects or something like that.

These properties are found in the equals and hashcode. (When not there is no issue.).

The following happens. If I still want to remove an object which was changed afterwards, in the method: public E remove(final int index),
inside public E remove(final int index) false is returned. But the object is still removed and in the debugger the following can be seen:

DEBUG Info:

this.collections.map.size == 5 (internal HashMap)
this.collections.setOrder.size == 4. (internal ArrayList)

Afterwards if I print the list with the overrided toString() method IndexOutOfBoundsException is thrown when getting the size of mySet
via mySet.size(), but not when I use an iterator to count the objects in the set.

{code:java}
public int getSize() {

OrderedIterator it = mySet.iterator();
int i = 0;
while(it.hasNext()){

it.next();
i++;

}
//if i return i then the items are 4, when returning memorySet.size(), the items are 5.
// return i;
return mySet.size();

}

@Override
public String toString() {

String toReturn = "\n";


for (int i = 0; i < getSize(); i++) {


toReturn = toReturn + mySet.get(i) + "\n";


}
return toReturn;

}
{code}

So my question is: is this a bug or is it because of my changing/updating the objects in the list, and why if it returns false when removing it got deleted anyway?
Should it not got deleted to start with?

Thank you for your effort.

P.S. I am a self taught programmer. It's my first time sending a bug issue, maybe it's a bit long or I did not send with it other information I should have.
2 years, 42 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i34267:
Commons Collections COLLECTIONS-584

Deserializing an AbstractHashedMap expands the hash table exponentially

Bug Closed Major Invalid Unassigned Diogo Sousa Diogo Sousa 14/Dec/15 18:08   14/Dec/15 22:49 14/Dec/15 18:51 4.1       0 1   When deserializing an {{AbstractHashedMap}} the size of the hashtable will be doubled at each element inserted because {{threshold}} = 0, so this

{code}
protected void checkCapacity() {
if(this.size >= this.threshold) {
int newCapacity = this.data.length * 2;
if(newCapacity <= 1073741824) {
this.ensureCapacity(newCapacity);
}
}
}
{code}

will always expand the hashtable.
4 years, 14 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2pvan:
Commons Collections COLLECTIONS-586

PatriciaTrie prefixMap clear throws NullPointerException

Bug Closed Major Fixed Unassigned Shailender Bathula Shailender Bathula 12/Apr/16 21:59   18/Jul/17 18:56 04/Aug/16 17:33 4.1       0 4   Clearing all entries of a prefixMap returned by PatriciaTrie using the {{clear}} method throws a NullPointerException. The workaround of removing each entry using the {{remove}} method seems to work.

Here are the test cases for the bug and the workaround:

{code:java}
public class PatriciaTrieTest {

private Trie<String, Integer> trie;

@Before
public void setUp() {
trie = new PatriciaTrie<Integer>();
trie.put("Anna", 1);
trie.put("Anael", 2);
trie.put("Analu", 3);
trie.put("Andreas", 4);
trie.put("Andrea", 5);
trie.put("Andres", 6);
trie.put("Anatole", 7);
}

@Test
public void testPrefixMapClear() {
SortedMap<String, Integer> prefixMap = trie.prefixMap("And");
assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet());
assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values()));

prefixMap.clear();
assertTrue(prefixMap.keySet().isEmpty());
assertTrue(prefixMap.values().isEmpty());
assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet());
assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values()));
}

@Test
public void testPrefixMapClearUsingRemove() {
SortedMap<String, Integer> prefixMap = trie.prefixMap("And");
assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet());
assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values()));

Set<String> keys = new HashSet<String>(prefixMap.keySet());
for (final String key : keys) {
prefixMap.remove(key);
}
assertTrue(prefixMap.keySet().isEmpty());
assertTrue(prefixMap.values().isEmpty());
assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet());
assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values()));
}

}
{code}

The stacktrace of the NullPointerException thrown by the {{testPrefixMapClear}} test case is:
{noformat}
java.lang.NullPointerException
at org.apache.commons.collections4.trie.AbstractPatriciaTrie$PrefixRangeEntrySet$EntryIterator.remove(AbstractPatriciaTrie.java:2370)
at java.util.AbstractCollection.clear(AbstractCollection.java:432)
at java.util.AbstractMap.clear(AbstractMap.java:288)
at PatriciaTrieTest.testPrefixMapClear(PatriciaTrieTest.java:39)
{noformat}
2 years, 35 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2w0vz:
Commons Collections COLLECTIONS-710

NullPointerExceptions in CompositeCollection, CompositeSet, and CompositeMap

Bug Resolved Major Fixed Unassigned Yu Shi Yu Shi 29/Jan/19 22:00   09/Feb/19 23:01 09/Feb/19 23:01 4.2 4.4 Collection, Map, Set   0 1 3600 3600 0% Windows 10

Eclipse IDE for Java Developers     Version: 2018-09 (4.9.0)
If we first add a null element into CompositeCollection by CompositeCollection.addComposited(nullElement), projects will crash and throw java.lang.NullPointerException when we call CompositeCollection.size().

For example, we have following code:

ArrayList<String> nullList = null;
CompositeCollection<String> cc = new CompositeCollection<String>(list);
cc.addComposited(nullList);
System.out.println(cc.size());

 

We will get:

{{Exception in thread "main" java.lang.NullPointerException}}
at org.apache.commons.collections4.collection.CompositeCollection.size(CompositeCollection.java:103)

 

Because in CompositeCollection.size(), it iterate all items in the Collection, call item.size() and sum up their size. If the item point to null, the program will crash.

 

This bug also exists in other methods of CompositeCollection. Moreover, CompositeSet and CompositeMap have the same bug.
0% 0% 3600 3600 nullpointerexception
1 year, 5 weeks, 3 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|yi0gfk:
Commons Collections COLLECTIONS-695

PatriciaTrie.subMap() does not return the expected outcome

Bug Resolved Major Invalid Unassigned Konrad Windszus Konrad Windszus 13/Sep/18 17:29   09/Oct/18 10:05 09/Oct/18 10:05 4.2       0 1   I use a {{PatriciaTrie}} to basically retrieve the entry whose key is the longest prefix of a requested key.

Now I do have a simple trie with only two entries:
# {{"/":<somevalue>}}
# {{"/libs/cq/flow/widgets":<someothervalue>"}}

If I call {{subMap("/", "/libs/cq/gui/components/authoring/dialog/"}} I would expect to only get back a map containing only entry 1. Instead I get back both entries. This happens primarily with those two specific keys.

According to the javadoc of {{PatriciaTrie}}
{quote}
The Trie can return operations in lexicographical order using the 'prefixMap', 'submap', or 'iterator' methods.
{quote}
(https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/trie/PatriciaTrie.html)
therefore I assumed that according to the lexicographical order only the "/" entry should be contained in here.

Is this a bug or am I misinterpreting the Javadoc?
1 year, 23 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3y2gn:
Commons Collections COLLECTIONS-689

Link to Javadoc API broken

Bug Closed Minor Fixed Unassigned Richard Walker Richard Walker 17/Jul/18 06:51   18/Jul/18 23:53 17/Jul/18 16:08 4.2 4.3 Collection   0 1   On the front page [https://commons.apache.org/proper/commons-collections/] in the Documentation section, the link to the Javadoc API for "The current release 4.2" is broken.
1 year, 34 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3vyo7:
Commons Collections COLLECTIONS-593

Compilation errors (generics) with JDK9

Bug Closed Major Not A Problem Unassigned Vincent Privat Vincent Privat 03/Jul/16 18:55   28/Mar/17 22:54 28/Mar/17 22:54 4.x       0 3   Java 9b125 Current codebase does not compile with JDK9 (build 125): 28 errors below.

I am not sure if this is a bug of JDK9 of a stricter compilation rule with generics.

[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/BagUtils.java:98: error: incompatible types: Bag<CAP#1> cannot be converted to Bag<E>
[javac] return UnmodifiableBag.unmodifiableBag(bag);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableBag(Bag<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:795: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C>
[javac] final Collection<C> resultCollection = collect(collection, transformer);
[javac] ^
[javac] where C is a type-variable:
[javac] C extends Object declared in method <C>transform(Collection<C>,Transformer<? super C,? extends C>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends C from capture of ? extends C
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:1835: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C>
[javac] return UnmodifiableCollection.unmodifiableCollection(collection);
[javac] ^
[javac] where C is a type-variable:
[javac] C extends Object declared in method <C>unmodifiableCollection(Collection<? extends C>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends C from capture of ? extends C
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/FluentIterable.java:311: error: incompatible types: FluentIterable<CAP#1> cannot be converted to FluentIterable<O>
[javac] return of(IterableUtils.transformedIterable(iterable, transformer));
[javac] ^
[javac] where O,E are type-variables:
[javac] O extends Object declared in method <O>transform(Transformer<? super E,? extends O>)
[javac] E extends Object declared in class FluentIterable
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O from capture of ? extends O
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:429: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<O>
[javac] return IteratorUtils.transformedIterator(iterable.iterator(), transformer);
[javac] ^
[javac] where O,I are type-variables:
[javac] O extends Object declared in method <I,O>transformedIterable(Iterable<I>,Transformer<? super I,? extends O>)
[javac] I extends Object declared in method <I,O>transformedIterable(Iterable<I>,Transformer<? super I,? extends O>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O from capture of ? extends O
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:833: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[])
[javac] return partition(iterable, factory, predicates);
[javac] ^
[javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>) is not applicable
[javac] (cannot infer type-variable(s) O#1
[javac] (actual and formal argument lists differ in length))
[javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...) is not applicable
[javac] (cannot infer type-variable(s) O#2
[javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#2>))
[javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable
[javac] (cannot infer type-variable(s) O#3,R
[javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>))
[javac] where O#1,O#2,O#3,R are type-variables:
[javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>)
[javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...)
[javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#1 from capture of ? extends O#1
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:873: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[])
[javac] return partition(iterable, factory, predicates);
[javac] ^
[javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>) is not applicable
[javac] (cannot infer type-variable(s) O#2
[javac] (actual and formal argument lists differ in length))
[javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...) is not applicable
[javac] (cannot infer type-variable(s) O#1
[javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#1>))
[javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable
[javac] (cannot infer type-variable(s) O#3,R
[javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>))
[javac] where O#1,O#2,O#3,R are type-variables:
[javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...)
[javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>)
[javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#1 from capture of ? extends O#1
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:438: error: incompatible types: BoundedIterator<CAP#1> cannot be converted to BoundedIterator<E>
[javac] return boundedIterator(iterator, 0, max);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>boundedIterator(Iterator<? extends E>,long)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:862: error: incompatible types: PeekingIterator<CAP#1> cannot be converted to Iterator<E>
[javac] return PeekingIterator.peekingIterator(iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>peekingIterator(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:878: error: incompatible types: PushbackIterator<CAP#1> cannot be converted to Iterator<E>
[javac] return PushbackIterator.pushbackIterator(iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>pushbackIterator(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1086: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] final List<E> list = toList(iterator, 100);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>toArray(Iterator<? extends E>,Class<E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1104: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] return toList(iterator, 10);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>toList(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/ListUtils.java:394: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] return UnmodifiableList.unmodifiableList(list);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableList(List<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1272: error: incompatible types: Map<CAP#1,CAP#2> cannot be converted to Map<K,V>
[javac] return UnmodifiableMap.unmodifiableMap(map);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>)
[javac] where CAP#1,CAP#2 are fresh type-variables:
[javac] CAP#1 extends K from capture of ? extends K
[javac] CAP#2 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1537: error: incompatible types: SortedMap<K,CAP#1> cannot be converted to SortedMap<K,V>
[javac] return UnmodifiableSortedMap.unmodifiableSortedMap(map);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MultiSetUtils.java:85: error: incompatible types: MultiSet<CAP#1> cannot be converted to MultiSet<E>
[javac] return UnmodifiableMultiSet.unmodifiableMultiSet(multiset);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableMultiSet(MultiSet<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/PredicateUtils.java:537: error: incompatible types: Predicate<CAP#1> cannot be converted to Predicate<T>
[javac] return TransformedPredicate.transformedPredicate(transformer, predicate);
[javac] ^
[javac] where T is a type-variable:
[javac] T extends Object declared in method <T>transformedPredicate(Transformer<? super T,? extends T>,Predicate<? super T>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends T from capture of ? extends T
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/QueueUtils.java:56: error: incompatible types: Queue<CAP#1> cannot be converted to Queue<E>
[javac] return UnmodifiableQueue.unmodifiableQueue(queue);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableQueue(Queue<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:225: error: incompatible types: Set<CAP#1> cannot be converted to Set<E>
[javac] return UnmodifiableSet.unmodifiableSet(set);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableSet(Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:505: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] return IteratorUtils.filteredIterator(a.iterator(), notContainedInB);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>difference(Set<? extends E>,Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:543: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] return IteratorUtils.filteredIterator(a.iterator(), containedInB);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>intersection(Set<? extends E>,Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:187: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2>
[javac] return FactoryTransformer.factoryTransformer(factory);
[javac] ^
[javac] where I#1,O#1,O#2,I#2 are type-variables:
[javac] I#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>)
[javac] O#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>)
[javac] O#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>)
[javac] I#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#2 from capture of ? extends O#2
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:235: error: incompatible types: Transformer<CAP#1,CAP#1> cannot be converted to Transformer<T,T>
[javac] return IfTransformer.ifTransformer(predicate, trueTransformer);
[javac] ^
[javac] where T is a type-variable:
[javac] T extends Object declared in method <T>ifTransformer(Predicate<? super T>,Transformer<? super T,? extends T>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends T from capture of ? extends T
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:428: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2>
[javac] return MapTransformer.mapTransformer(map);
[javac] ^
[javac] where I#1,O#1,O#2,I#2 are type-variables:
[javac] I#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>)
[javac] O#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>)
[javac] O#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>)
[javac] I#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#2 from capture of ? extends O#2
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TrieUtils.java:46: error: incompatible types: Trie<K,CAP#1> cannot be converted to Trie<K,V>
[javac] return UnmodifiableTrie.unmodifiableTrie(trie);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/iterators/IteratorIterable.java:118: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] this.typeSafeIterator = createTypesafeIterator(this.iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in class IteratorIterable
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/multimap/TransformedMultiValuedMap.java:162: error: incompatible types: FluentIterable<CAP#1> cannot be converted to Iterable<V>
[javac] final Iterable<V> transformedValues = FluentIterable.of(values).transform(valueTransformer);
[javac] ^
[javac] where V is a type-variable:
[javac] V extends Object declared in class TransformedMultiValuedMap
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/imaging/util/Debug.java:125: error: incompatible types: ArrayList<CAP#1> cannot be converted to List<Object>
[javac] final List<Object> keys = new ArrayList<>(map.keySet());
[javac] ^
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends Object from capture of ?
[javac] 28 errors
[javac] 1 warning
generics, jdk9, josm-found
3 years, 10 weeks, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i30hcn:
Commons Collections COLLECTIONS-470

TransformedMap class exists in two packages

Bug Closed Major Fixed Unassigned Sebb Sebb 14/May/13 15:15   09/Nov/14 14:31 11/Jun/13 20:29 4.x 4.0-alpha1, 4.0     0 0   It's very confusing to have two different TransformedMap classes in different packages: map, splitmap.
Indeed the Test class has to take special care with the serialised file name to avoid a clash.

Since we can break binary compat in v4, now is the time to rename one of the classes.

Perhaps rename as follows:
splitmap/TransformedMap => splitmap/TransformedGetPutMap
6 years, 41 weeks ago 327876 No Perforce job exists for this issue. 0 328220 0|i1kkkf:
Commons Collections COLLECTIONS-519

private constructors in utility classes break existing code

Bug Closed Major Won't Fix Unassigned Radoslav Paskalev Radoslav Paskalev 22/Apr/14 10:05   27/Nov/15 21:47 02/May/14 09:00 4.x       1 4   Hello,

In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils....) have private constructors. I consider this to be a serious bug, as it breaks any possibility the classes to be extended by the users. The javadoc says that constructors are private in order to prevent class instantiation but this object instantiation is not really problem and i think it is more important to allow classes to be extended. The possibility to extend utility classes was one of the major selling points of commons.lang and commons.collections projects. In the latest commons.lang project the utility classes still have public constructors.


Best Regards
5 years, 46 weeks, 4 days ago 388053 No Perforce job exists for this issue. 0 388311 0|i1uui7:
Commons Collections COLLECTIONS-372

ComparatorUtils.transformedComparator wrongly typed (generics)

Bug Closed Minor Fixed Unassigned HaveNone HaveNone 18/Mar/11 12:45   09/Nov/14 14:31 06/Mar/13 19:52 4.x 4.0-alpha1, 4.0 Comparator   1 0   n/a ComparatorUtils.transformedComparator is currently typed as follows :

{{public static <I,O> Comparator<O> transformedComparator(Comparator<I> comparator, Transformer<I, O> transformer)}}

It should be typed as follows so that is can be used without removing generics typing:
{{public static <I,O> Comparator<I> transformedComparator(Comparator<O> comparator, Transformer<I, O> transformer)}}

Here is a unit test for it :
Transformer<Integer, String> itosTransformer = TransformerUtils.stringValueTransformer();
Comparator<Integer> c = new Comparator<Integer>() {

@Override
public int compare(Integer o1, Integer o2) {
return o1.compareTo(o2);
}
};
Comparator<String> stringComparator = ComparatorUtils.transformedComparator(c, itosTransformer);

stringComparator.compare("string1", "string2");
patch 7 years, 2 weeks, 6 days ago 18631 No Perforce job exists for this issue. 0 90356 0|i0ftdb:
Commons Collections COLLECTIONS-447

TreeListIterator can return incorrect results after remove() is called

Bug Closed Major Fixed Unassigned Jeffrey Barnes Jeffrey Barnes 03/Mar/13 03:24   09/Nov/15 20:53 04/Mar/13 20:20 Nightly Builds 3.2.2, 4.0-alpha1, 4.0 Collection   0 1   Windows 7, jdk1.5.0_22 {{TreeList.TreeListIterator}} can get in a bad state when {{remove()}} is called, causing it to subsequently return incorrect results. This is because {{TreeListIterator}} caches an {{AVLNode}} reference in its field {{next}}, and this node reference may become stale when {{remove()}} is called (it may contain a reference to a node that no longer exists in the tree).

I will attach two patches: {{testcase.patch}} will contain a test case illustrating the bug, and {{fix.patch}} will contain a fix. (To fix the bug, I simply clear the cached {{next}} value in {{TreeListIterator.remove}}.)

This was originally reported in a comment to COLLECTIONS-433; I am creating a separate issue for this at Thomas Neidhart's suggestion.
patch, test 7 years, 3 weeks, 1 day ago 315498 No Perforce job exists for this issue. 2 315842 0|i1ifxz:
Commons Collections COLLECTIONS-414

Collections does not compile with openjdk 1.6.0_24

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 23/Jun/12 12:31   09/Nov/14 14:31 15/Jul/12 11:19 Nightly Builds 4.0-alpha1, 4.0     0 1   There are several classes for which generic type inference does not work when using the openjdk 1.6.0_24 compiler:

{noformat}
[ERROR] /home/tn/workspace/apache/commons-collections/src/main/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments
[ERROR] required: org.apache.commons.collections.Predicate<? super java.lang.Object>[]
[ERROR] found: org.apache.commons.collections.Predicate<? super T>[]
{noformat}

This is mainly due to re-using a method argument that is restricted by Predicate<? super T> to assign methods results of type Predicate<T>.

The eclipse compiler does not report an error in these cases.
7 years, 39 weeks, 3 days ago 292944 No Perforce job exists for this issue. 0 164346 0|i0shpj:
Commons Collections COLLECTIONS-601

commons-collections unit tests broken in Java 8

Bug Resolved Major Cannot Reproduce Unassigned Allon Mureinik Allon Mureinik 20/Mar/17 10:38   25/May/17 11:07 24/May/17 08:25 Nightly Builds       0 2   Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full details in attached logs Building the upstream trunk (currently, patch 30b2aca) fails the unit tests in Java 8, but passes in Java 7 on the same machine. Attached logs with env details an errors of a successful Java 7 build and an unsuccessful Java 8 build test
2 years, 42 weeks, 5 days ago 9223372036854775807 No Perforce job exists for this issue. 2 9223372036854775807 0|i3ciav:
Commons Collections COLLECTIONS-255

Unused variable in TreeBidiMap.java

Bug Closed Trivial Fixed Unassigned Henri Yandell Henri Yandell 08/Jun/07 00:32   09/Nov/14 14:31 28/Feb/13 19:55 Nightly Builds 4.0-alpha1, 4.0 BidiMap   0 0   Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time.

We should either:

a) Delete the variable.
b) Use the variable and always return the same TreeView.

I'm thinking a).

[Found via http://opensource.fortifysoftware.com/ ]
10 years, 13 weeks ago 18745 No Perforce job exists for this issue. 1 164468 0|i0sign:
Commons Collections COLLECTIONS-135

[PATCH] SwitchTransformer doc/impl inconsistent

Bug Closed Trivial Fixed Unassigned Matt Benson Matt Benson 05/Apr/06 05:38   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
TransformerUtils says that a null defaultTransformer will return null; this is
consistent with the switchTransformer tests under TestTransformerUtils.
However, the SwitchTransformer constructor's javadoc says that a null
defaultTransformer means nop, which is incorrect. Not that it matters, but NOP
would have been more intuitive IMHO, but what's done is done and passing
NOPTransformer.INSTANCE or TransformerUtils.nopTransformer() is no big deal.
13 years, 51 weeks ago 18863 No Perforce job exists for this issue. 1 39207 164573 0|i0sj3z:
Commons Collections COLLECTIONS-117

[collections][PATCH] correct misspelling in RELEASE-NOTES.html

Bug Closed Trivial Fixed Unassigned Matt Benson Matt Benson 06/Jan/06 02:45   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
s/COMPATABILITY/COMPATIBILITY/
14 years, 12 weeks, 3 days ago 18881 No Perforce job exists for this issue. 1 38140 164591 0|i0sj7z:
Commons Collections COLLECTIONS-114

[collections] Build Warnings when building under JDK 1.5

Bug Closed Major Fixed Unassigned Will Pugh Will Pugh 23/Jun/05 03:36   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
When I build under JDK 1.5 on MacOSX, I get a bunch of warnings. Almost all of
them are a result of some APIs moving over to using varargs. Here is an example
of some of the warnings. The fixes in just about all cases was to cast a null
to either (Method[]) or (Object[]). in one place a temporary array new String[]
{ ... } had to be changed to new Object[] { ... }

[javac] Compiling 271 source files to
/Users/willpugh/projects/beanutils2/collections2/collections/target/classes
/Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:62:
warning: non-varargs call of varargs method with inexact argument type for last
parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
Method method = prototype.getClass().getMethod("clone", null);
^
/Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:119:
warning: non-varargs call of varargs method with inexact argument type for last
parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
iCloneMethod = iPrototype.getClass().getMethod("clone", null);

. . .
14 years, 40 weeks, 3 days ago 18884 No Perforce job exists for this issue. 1 35474 164594 0|i0sj8n:
Commons Collections COLLECTIONS-68

[collections] Concurrent modification in FastArrayList

Bug Closed Major Fixed Unassigned Guilhem Lavaux Guilhem Lavaux 01/May/05 03:11   15/Mar/08 21:35 14/Jul/06 12:04 Nightly Builds       1 0   Operating System: All
Platform: All
I confirm a bug highlighted by GNU Classpath internal checkings concerning
FastArrayList. It uses two different paths for modifying a list and accessing it
in FastArrayList$ListIter.remove.

On 2005-04-30 SVN snapshot the line which causes problem is at
org.apache.commons.collections.FastArrayList$ListIter.remove
(FastArrayList.java:1308)

because previousIndex() is used on an iterator which has not followed the
modification introduced by a call to List.remove.

This bug is not detected by Sun's JDK.
13 years, 37 weeks, 4 days ago 18930 No Perforce job exists for this issue. 0 34690 164640 0|i0sjiv:
Commons Collections COLLECTIONS-56

NoSuchElementException in ReferenceMap views

Bug Closed Major Fixed Unassigned Joe Raysa Joe Raysa 16/Dec/03 08:57   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: All
Platform: PC
The keySet() and values() views for the
org.apache.commons.collections.map.ReferenceMap class will throw a
NoSuchElementException in their toArray(Object[]) methods if any keys or values
have been reclaimed by the garbage collector and purge() has not been invoked.
The toArray(Object[]) implementation inherited from
java.util.AbstractCollection uses size()-based iteration rather than hasNext()-
based iteration. This is inappropriate because the size of the map can change
during iteration. The problem is exacerbated by the fact that neither the
KeySet nor Values classes purge stale elements from the list in their size()
methods.

The attached test case reliably reproduces this exception with Sun's 1.3.1_07
and 1.4.2 Win2K Hotspot VMs.

The attached diff is a proposed fix for this issue.
16 years, 14 weeks, 1 day ago 18942 No Perforce job exists for this issue. 2 25551 164652 0|i0sjlj:
Commons Collections COLLECTIONS-97

[collections][PATCH] JavaDoc fixes for iterators

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 11/Sep/03 04:50   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch fixes three typos in ComparatorChain, FixedOrderComparator
and TransformingComparator.
16 years, 28 weeks, 6 days ago 18901 No Perforce job exists for this issue. 1 23087 164611 0|i0sjcf:
Commons Collections COLLECTIONS-25

[collections][PATCH] OutOfMemoryError test case for MapUtils.verbosePrint.

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 10/Sep/03 04:02   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch adds a test case to TestMapUtils that demonstrates infinite
recursion in MapUtils.verbosePrint.
16 years, 28 weeks, 5 days ago 18973 No Perforce job exists for this issue. 2 23041 164683 0|i0sjsf:
Commons Collections COLLECTIONS-136

[collections][PATCH] CollectionUtils.getFreq optimization

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 09/Sep/03 03:59   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch improves the performance of CollectionUtils.getFreq(Object,
Map) by using a test in place of a thrown exception.

The effect of the change was measured with the class below. These are the times
for the Sun JDK 1.4.1_03 on Red Hat Linux 8.0

pre-optimization: 122534
post-optimization: 104637

The patch reduced the time to run the test to 85% of the original.

The also patch removes a catch of NoSuchElementException which, as far as I can
tell, was unnecessary in the original code.

This is the test class:

import org.apache.commons.collections.CollectionUtils ;

import java.util.*;

public class CollectionUtilsTest {


Set a ;
Set b ;
Set c ;

Collection cols [] ;

long startMillis ;
void init () {

a = new HashSet () ;
for ( int i = 1 ; i <= 10000 ; i++ ) {
a.add ( new Integer ( i ) ) ;
}

b = new HashSet () ;
for ( int i = 5001 ; i <= 15000 ; i++ ) {
b.add ( new Integer ( i ) ) ;
}

c = new HashSet () ;
for ( int i = 10001 ; i <= 20000 ; i++ ) {
c.add ( new Integer ( i ) ) ;
}

cols = new Collection [] { a, b, c } ;

startMillis = System.currentTimeMillis () ;
}


void run () {

for ( int i = 0 ; i < 3 ; i++ ) {
for ( int j = 0 ; j < 3 ; j++ ) {
CollectionUtils.union ( cols [ i ], cols [ j ] ) ;
CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ;
CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ;
CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ;
}
}

}


void report () {

System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () -
startMillis ) ) ;
}



public static void main ( String [] arg ) {

CollectionUtilsTest t = new CollectionUtilsTest () ;

t.init () ;
t.run () ;
t.report () ;

}
}
16 years, 29 weeks, 6 days ago 18862 No Perforce job exists for this issue. 1 23004 164572 0|i0sj3r:
Commons Collections COLLECTIONS-58

[collections] [PATCH] patch to reduce object creation in CollectionUtils

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 08/Sep/03 05:29   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch reduces the number of Integer objects created when invoking
CollectionUtils.getCardinalityMap(final Collection col). The number of Integers
created is reduced by the count of unique objects within col.

The patch does not change the basic algorithm so the simplicity of the method is
not lost.

The change was profiled with the class below. These are the absolute times for
JDK 1.3.1_04 and 1.4.1_03

1.4 1.3
pre: 168267 153849
post: 164473 150866

and normalised to the pre version for each JDK

1.4 1.3
pre: 1.00 1.00
post: 0.98 0.98

so there was only a minor speed difference however the reduction in the number
of created objects has a memory use advantage. It was surprising to see that JDK
1.4.1 was slower than 1.3.1, in this limited test. The binaries were compiled
with JDK 1.4.1.

This is the test class:

import org.apache.commons.collections.CollectionUtils ;

import java.util.*;

public class CollectionUtilsTest {


Set a ;
Set b ;
Set c ;

Collection cols [] ;

long startMillis ;
void init () {

a = new HashSet () ;
for ( int i = 1 ; i <= 10000 ; i++ ) {
a.add ( new Integer ( i ) ) ;
}

b = new HashSet () ;
for ( int i = 5001 ; i <= 15000 ; i++ ) {
b.add ( new Integer ( i ) ) ;
}

c = new HashSet () ;
for ( int i = 1001 ; i <= 20000 ; i++ ) {
c.add ( new Integer ( i ) ) ;
}

cols = new Collection [] { a, b, c } ;

startMillis = System.currentTimeMillis () ;
}


void run () {

for ( int i = 0 ; i < 3 ; i++ ) {
for ( int j = 0 ; j < 3 ; j++ ) {
CollectionUtils.union ( cols [ i ], cols [ j ] ) ;
CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ;
CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ;
CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ;
}
}

}


void report () {

System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () -
startMillis ) ) ;
}



public static void main ( String [] arg ) {

CollectionUtilsTest t = new CollectionUtilsTest () ;

t.init () ;
t.run () ;
t.report () ;

}
}
16 years, 29 weeks, 6 days ago 18940 No Perforce job exists for this issue. 1 22973 164650 0|i0sjl3:
Commons Collections COLLECTIONS-125

[collections] [PATCH] MapUtils JavaDoc fixes

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 08/Sep/03 04:35   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch modifies some documentation tags and fixes the code example
for MapUtils.lazySortedMap.
16 years, 29 weeks, 6 days ago 18873 No Perforce job exists for this issue. 1 22972 164583 0|i0sj67:
Commons Collections COLLECTIONS-90

[collections][PATCH] JavaDoc simplification for CollectionUtils

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 07/Sep/03 08:40   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch removes some extraneous @return and @throws tags and makes
the effect of a null Predicate easier to understand for a couple of methods.
16 years, 30 weeks, 2 days ago 18908 No Perforce job exists for this issue. 1 22964 164618 0|i0sjdz:
Commons Collections COLLECTIONS-112

[collections] [PATCH] fixes some @author hrefs or removes the link markup

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 07/Sep/03 06:43   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patches are mutually exclusive and either fix some hrefs in some
@author tags which are missing 'mailto:' prefixes or (to match a recently
applied collections patch) remove the link markup altogether.
16 years, 30 weeks, 2 days ago 18886 No Perforce job exists for this issue. 2 22962 164596 0|i0sj93:
Commons Collections COLLECTIONS-19

[collections] 'acknowledgement' typos in licence headers

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 31/Aug/03 08:58   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The Apache Software License includes these typos in various files

'acknowlegement' in 54 files
'acknowledgment/acknowledgements' in 519 files
16 years, 31 weeks, 2 days ago 18979 No Perforce job exists for this issue. 0 22845 164689 0|i0sjtr:
Commons Collections COLLECTIONS-119

[collections] Misnamed method in FixedOrderComparator: getUnkownObjectBehavior

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 31/Aug/03 08:45   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The method is probably meant to be getUnknownObjectBehavior()

From the class:

FixedOrderComparator {

...

/**
* Gets the behavior for comparing unknown objects.
*/
public int getUnkownObjectBehavior() {
return unknownObjectBehavior;
}

...
}
16 years, 31 weeks, 2 days ago 18879 No Perforce job exists for this issue. 0 22844 164589 0|i0sj7j:
Commons Collections COLLECTIONS-47

[collections] [PATCH] fixes 97 typos

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 31/Aug/03 08:35   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch fixes 97 typos in the version of collections from 03-August-31.
16 years, 31 weeks, 1 day ago 18951 No Perforce job exists for this issue. 1 22843 164661 0|i0sjnj:
Commons Collections COLLECTIONS-54

[collections][PATCH] increase number of tests run from 2484 to 7429

Bug Closed Critical Fixed Unassigned Janek Bogucki Janek Bogucki 14/Sep/03 04:29   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached file patches build.xml to use 'TestAllPackages' instead of
'TestAll' for the value of 'test.entry'. This results in a greater number of
tests being run.

project.xml also uses 'TestAll' but there this patch does not fix that becuase I
am not using maven.

(I find this situation a bit odd because Stephen Colebourne mentioned that some
bugs had been detected in o.a.c.collections.observed package a few days ago by
some tests and as far as I can see those tests would not have run without this
change. Is the use of ant deprecated or am I just not seeing something obvious
or customary?)
16 years, 28 weeks, 6 days ago 18944 No Perforce job exists for this issue. 1 23155 164654 0|i0sjlz:
Commons Collections COLLECTIONS-20

[collections] TestObservedBag and TestObservedSet fail under Java 1.3.1

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 17/Sep/03 03:05   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
With CVS HEAD of 2003-Sept-16 two unit tests fail under Java 1.3.1_04.

$ java -version
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)

The stack trace is:

[java] There were 2 failures:
[java] 1) testObservedSet(o.a.c.collections.observed.TestObservedBag)
junit.framework.AssertionFailedError: expected same:<7> was not:<6>
[java] at
o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedBag(ObservedTestHelper.java:188)
[java] at
o.a.c.collections.observed.TestObservedBag.testObservedSet(TestObservedBag.java:98)
[java] 2) testObservedSet(o.a.c.collections.observed.TestObservedSet)
junit.framework.AssertionFailedError: expected same:<7> was not:<6>
[java] at
o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedSet(ObservedTestHelper.java:164)
[java] at
o.a.c.collections.observed.TestObservedSet.testObservedSet(TestObservedSet.java:106)

[java] FAILURES!!!
[java] Tests run: 7489, Failures: 2, Errors: 0


It doesn't matter whether it is compiled with 1.4.1 or 1.3.1 as summarized here:

Run with:

1.3.1_04 1.4.1_03

Compiled with: 1.3.1_04 fail pass

1.4.1_03 fail pass
16 years, 28 weeks, 3 days ago 18978 No Perforce job exists for this issue. 0 23201 164688 0|i0sjtj:
Commons Collections COLLECTIONS-16

ExtendedProperties never sets isInitialized

Bug Closed Major Fixed Unassigned Walt Walt 18/Jan/03 06:16   15/Mar/08 21:35 14/Jul/06 12:05 Nightly Builds       1 0   Operating System: All
Platform: All
ExtendedProperties.isInitialized() is always false. The only code that sets it
is in a private init() function that is never called. Some other apps (Torque)
have depended on isInitialized being set to true after a load but apparently the
Torque devs never realized it wasn't.

I'll attach a patch to correct this. The patch removes the private, never used,
init() function and sets isInitialized on either a load() or addProperty().
13 years, 37 weeks, 4 days ago 18982 No Perforce job exists for this issue. 1 16225 164692 0|i0sjuf:
Commons Collections COLLECTIONS-1

[collections] Collections Javadoc warnings with JDK 1.4.2

Bug Closed Major Fixed Unassigned Eric Johnson Eric Johnson 09/Oct/03 00:57 18/Mar/20 02:33 14/Jul/06 05:48 14/Jul/06 05:48 Nightly Builds 3.0     0 0   Operating System: All
Platform: All
Numerous javadoc warnings when doing "ant dist" target under JDK 1.4.2. Partial
patch to follow
14 years, 35 weeks, 5 days ago 18997 No Perforce job exists for this issue. 4 23680 164707 0|i0sjxr:
Commons Collections COLLECTIONS-126

[patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap

Bug Closed Major Incomplete Unassigned Jari Aalto Jari Aalto 23/Jul/02 23:14   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: All
Platform: PC
Environment:

Win32 W2kSp2 / cygwin
Win32 JDK 1.4.1
CVS ant
CVS jakarta-commons

There is problem with compiling. See attached patch, which I AM NOT
SURE if it is correct solution. At least it builds without this error.

- jari

root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ ant.bat
Buildfile: build.xml

init:

build-java:

build-test:
[javac] Compiling 62 source files to D:\java\apache\cvs\jakarta-
commons\collections\dist\classes
[javac] D:\java\apache\cvs\jakarta-
commons\collections\src\test\org\apache\commons\collections\TestHashMap.java:74:
org.apache.commons.collections.TestHashMap should be declared abstract; it
does not define makeEmptyMap() in org.apache.commons.collections.TestMap
[javac] public class TestHashMap extends TestMap
[javac] ^
[javac] 1 error

BUILD FAILED
file:d:/java/apache/cvs/jakarta-commons/collections/build.xml:216: Compile
failed; see the compiler error output for details.

Total time: 20 seconds

==========================================================================

root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ diff -
u src/test/org/apache/commons/collections/TestHashMap.java.orig
src/test/org/apache/commons/collections/TestHashMap.java
--- src/test/org/apache/commons/collections/TestHashMap.java.orig 2001-07-
15 01:33:28.000000000 +0300
+++ src/test/org/apache/commons/collections/TestHashMap.java 2002-07-23
13:45:34.000000000 +0300
@@ -94,6 +94,11 @@
return (hm);
}

+ public Map makeEmptyMap()
+ {
+ return makeMap();
+ }
+
protected HashMap map = null;

public void setUp()
16 years, 41 weeks, 1 day ago 18872 No Perforce job exists for this issue. 1 11092 164582 0|i0sj5z:
Commons Collections COLLECTIONS-41

LazyCollections.lazyList.get(i) grows wrong

Bug Closed Major Fixed Unassigned Nikolaj Joergensen Nikolaj Joergensen 07/Aug/02 13:39   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
LazyCollections.lazyList.get(i) grows wrong when called with i == (size() -1).

If the list has 3 elements and LazyCollections.lazyList.get(2) is called then
size of the list will grow to size == 4 because within bounds check says:

if(index < (this.listImpl.size()-1) {

Should be:

if(index < this.listImpl.size()) {
17 years, 34 weeks ago 18957 No Perforce job exists for this issue. 1 11522 164667 0|i0sjov:
Commons Collections COLLECTIONS-9

[collections] ~20 Javadoc fixes and type cast clean ups.

Bug Closed Major Fixed Unassigned Gary D. Gregory ggregory@seagullsw.com 07/Jan/04 07:27   10/Mar/11 23:16 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: All
Platform: All
Please see patch file attached.
16 years, 12 weeks, 4 days ago 18989 No Perforce job exists for this issue. 1 25936 164699 0|i0sjvz:
Commons Collections COLLECTIONS-78

BinaryHeap.remove(Object) seems to break heap order

Bug Closed Major Fixed Unassigned Steve Phelps Steve Phelps 30/Dec/03 16:46   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: Linux
Platform: PC
I am currently attempting to migrate from my own implementation of a BinaryHeap
to the implementation in org.apache.commons.collections.BinaryHeap.

I have some existing unit tests for my implementation which fail when I run them
on the commons BinaryHeap. Below is source-code for the JUnit test which fails.
The test 'testRandom' is the test that fails. This test creates heaps
initialised with 100 randomly generated Integers and proceeds to add and remove
random elements from these heaps and then checks the heap order. Some of the
elements that are removed may not exist in the heap. Heap order is checked by
disassembling the heap using BinaryHeap.pop() and ensuring that subsequent
elements are >= earlier elements.

The problem appears to be related to the BinaryHeap.remove(Object) method-- if
this is commented out the test succeeds. It may be the case that the problem
occurs when non-existant elements are removed, but I have not attempted to
verify this.


---------
BinaryHeapTest.java
---------
/*
* JASA Java Auction Simulator API
* Copyright (C) 2001-2003 Steve Phelps
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details.
*/

package test.uk.ac.liv.util;

import test.uk.ac.liv.PRNGTestSeeds;

import junit.framework.*;

//import uk.ac.liv.util.*;

import org.apache.commons.collections.BinaryHeap;

import java.util.Random;
import java.util.Iterator;
import java.util.LinkedList;

public class BinaryHeapTest extends TestCase {

BinaryHeap h1;

public BinaryHeapTest( String name ) {
super(name);
}

public void setUp() {

h1 = new BinaryHeap();

h1.insert(new Integer(1));
h1.insert(new Integer(3));
h1.insert(new Integer(9));
h1.insert(new Integer(3));
h1.insert(new Integer(5));
h1.insert(new Integer(7));
}

public void test() {
System.out.println("h1 = " + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(5)) );
assertTrue( !h1.contains(new Integer(10)) );
assertTrue( !h1.contains(new Integer(-1)) );
Object x = h1.pop();
System.out.println("h1 after removing first = " + h1);
checkOrder(h1);
assertTrue( ((Integer) x).equals(new Integer(1)));
assertTrue( !h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(5)) );
h1.remove(new Integer(9));
System.out.println("h1 after removing 9 = " + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( !h1.contains(new Integer(9)) );
assertTrue( h1.remove( new Integer(3) ) );
System.out.println("h1 after removing 3 = " + h1);
// assertTrue( ! h1.contains(new Integer(3)) );
x = h1.pop();
System.out.println("h1 after removing first = " + h1);
h1.pop();
System.out.println("h1 after removing first = " + h1);
assertTrue( h1.remove( new Integer(7) ) );
System.out.println("h1 after removing 7 = " + h1);
assertTrue( h1.isEmpty() );
assertTrue( ! h1.remove( new Integer(7) ) );
h1.add( new Integer(666) );
h1.add( new Integer(667) );
assertTrue( h1.remove(new Integer(667)) );
assertTrue( h1.size() == 1 );
assertTrue( ! h1.contains(new Integer(667)) );
assertTrue( h1.remove(new Integer(666)) );

}


public void checkOrder( BinaryHeap h ) {
System.out.println("Checking order of " + h);
Integer lastNum = null;
LinkedList l = new LinkedList();
while ( !h.isEmpty() ) {
Integer num = (Integer) h.pop();
System.out.println(num);
if ( lastNum != null && num.intValue() < lastNum.intValue() ) {
System.out.println("!!??*** " + num + " smaller than " + lastNum);
}
assertTrue( lastNum == null || num.intValue() >= lastNum.intValue() );
lastNum = num;
l.add(num);
}
Iterator it = l.iterator();
while ( it.hasNext() ) {
h.add( it.next() );
}
}

public void testRandom() {
Random randGenerator = new Random(PRNGTestSeeds.UNIT_TEST_SEED);
for( int i=0; i<1000; i++ ) {
BinaryHeap h = new BinaryHeap();
for( int r=0; r<100; r++ ) {
h.add( new Integer( randGenerator.nextInt(100)) );
}
System.out.println("Starting with heap " + h);
for( int r=0; r<20; r++ ) {
System.out.println("Attempting to remove " + r);
System.out.println("result = " + h.remove( new Integer(r) ) );
Integer n = new Integer( randGenerator.nextInt(100) );
System.out.println("Adding " + n);
h.add(n);
}
checkOrder(h);
}
}


public static void main( String[] args ) {
junit.textui.TestRunner.run (suite());
}

public static Test suite() {
return new TestSuite(BinaryHeapTest.class);
}

}


/*
* JASA Java Auction Simulator API
* Copyright (C) 2001-2003 Steve Phelps
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details.
*/


-------
PRNGTestSeeds.java
-------

package test.uk.ac.liv;

/**
* The PRNG seed to use for deterministing unit-testing of seedable classes.
* This was introduced for ecj10, which uses a seed based on the
* current system time when using the null argument constructor.
*
* @author Steve Phelps
* @version $Revision: 1.2 $
*/

public class PRNGTestSeeds {

/**
* The seed to use for all unit tests.
*/
public static final long UNIT_TEST_SEED = 1465187;

}
16 years, 13 weeks, 4 days ago 18920 No Perforce job exists for this issue. 0 25818 164630 0|i0sjgn:
Commons Collections COLLECTIONS-60

Minor problems in SequencedHashMap and LRUMap

Bug Closed Major Fixed Unassigned Paul Jack Paul Jack 09/Jun/02 04:42   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
1. The remove(Object) methods in the keySet and entrySet correctly remove null
keys, but incorrectly return false after they do so.

2. The retainAll(Collection) and removeAll(Collection) methods in the
collection views do not properly modify the map's modCount, and thus will never
cause a ConcurrentModificationException.
17 years, 43 weeks, 2 days ago 18938 No Perforce job exists for this issue. 0 9719 164648 0|i0sjkn:
Commons Collections COLLECTIONS-99

[PATCH] Apidoc fix for MapUtils.java

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 20/Jun/03 07:36   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: All
Platform: All
This patch fixes two {@link} tags.
16 years, 41 weeks, 4 days ago 18899 No Perforce job exists for this issue. 1 20933 164609 0|i0sjbz:
Commons Collections COLLECTIONS-57

Addition of static class modifer to inner classes

Bug Closed Minor Fixed Unassigned Janek Bogucki Janek Bogucki 20/Jun/03 06:56   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: All
Platform: All
findbugs 0.6.0 suggested that these classes had inner classes which could be
made static

CursorableLinkedList.java
DefaultMapBag.java
ExtendedProperties.java
StaticBucketMap.java

The attached patch file patches these classes in that way. After patching the
unit test passed okay.

I'm assuming the unit tests passing is proof enough that these changes are okay.
16 years, 41 weeks, 4 days ago 18941 No Perforce job exists for this issue. 1 20931 164651 0|i0sjlb:
Commons Collections COLLECTIONS-4

Calling CollectionUtils.cardinality with null obj argument leads to NPE

Bug Closed Major Fixed Unassigned Serhiy Yevtushenko Serhiy Yevtushenko 20/Oct/02 03:27   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
There is a bug in cardinality method, which shows, when obj parameter is null;
It leads to NullPointerException.

In order to reveal it, add line

assertEquals(0, CollectionUtils.cardinality(null, _b));

to testCardinality in TestCollectionUtils.

One variant of correct implementation is following:

public static int cardinality(Object obj, final Collection col) {
int count = 0;
Iterator it = col.iterator();
if(null==obj){
while(it.hasNext()){
Object elt = it.next();
if(null==elt){
count++;
}
}
}else{
while(it.hasNext()) {
Object elt = it.next();
if(obj.equals(elt)) {
count++;
}
}
}
return count;
}
17 years, 22 weeks, 3 days ago 18994 No Perforce job exists for this issue. 0 13785 164704 0|i0sjx3:
Commons Collections COLLECTIONS-34

Collections doesn't build with jdk1.2 javac

Bug Closed Major Fixed Unassigned Jeff Turner Jeff Turner 12/May/01 05:46   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: Linux
Platform: PC
Hi,

Just tried building jakarta-commons/collections from CVS (12/5), and it doesn't
compile with Sun's 'javac' for linux:

$ java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2_007, green threads, nojit)

$ ant clean ; ant
....
build-java:
[mkdir] Created dir:
/home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes
[javac] Compiling 26 source files to
/home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes
[javac]
/home/jeff/apache/jakarta/jakarta-commons/collections/src/java/org/apache/commons/collections/FastTreeMap.java:325:
Inner type Entry in class java.util.TreeMap not accessible from class
org.apache.commons.collections.FastTreeMap.
[javac] Entry e = (Entry) i.next();
[javac] ^
[javac]
....
BUILD FAILED


However, it *does* work if I set build.compiler=jikes. It also works if I use
jdk1.3 'javac'. Possibly a bug in javac?

Anyway, just thought I'd bring this to people's attention, as the STATUS.html
file states it needs "JDK1.2 or later".

thanks,

--Jeff
18 years, 46 weeks, 5 days ago 18964 No Perforce job exists for this issue. 0 1729 164674 0|i0sjqf:
Commons Collections COLLECTIONS-31

[collections][PATCH] BlockingBuffer JavaDoc improvement

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 18/Sep/03 07:13   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch improvements the JavaDoc for
o.a.c.c.decorators.BlockingBuffer by describing the behaviour of get() and
remove() in a multithreaded environment.
16 years, 28 weeks, 5 days ago 18967 No Perforce job exists for this issue. 1 23234 164677 0|i0sjr3:
Commons Collections COLLECTIONS-89

[collections][PATCH] TestBlockingBuffer extensions and BlockingBuffer fix

Bug Closed Major Fixed Unassigned Janek Bogucki Janek Bogucki 18/Sep/03 06:31   15/Mar/08 21:36 15/Mar/08 21:36 Nightly Builds       0 0   Operating System: other
Platform: Other
The attached patch adds some tests to assert the behaviour of
BlockingBuffer.get()/remove()/add()/addAll in various combinations.

The discussion that led to this patch can be found at COM-816.

Also attached is a patch to change notify() to notifyAll() in BlockingBuffer
which allows the tests in TestBlockingBuffer to pass.
16 years, 28 weeks, 5 days ago 18909 No Perforce job exists for this issue. 2 23232 164619 0|i0sje7:
Commons Collections COLLECTIONS-44

Upgrade your version number

Bug Closed Minor Fixed Unassigned Arnaud HERITIER Arnaud HERITIER 11/Jul/02 21:05   15/Mar/08 21:35 15/Mar/08 21:35 Nightly Builds       0 0   Operating System: other
Platform: Other
Can you update your build xml to modify the component.version property.
It is actually setted to 2.0 and should be to 3.0 dev or 2.1 dev ??

Futhermore, the Manifest file is not automatically generated from build.xml
properties.

I attach a copy of the build.xml and the Manifest files that I modified to
automatically update the release number.

I let you to choose which number to use in the build.xml.

Here are diffs that I done from Cygwin because I can't access to the CVS
Repository from my office :-(

diff MANIFEST.MF :

5c5
< Implementation-Version: @version@
---
> Implementation-Version: 2.0

diff build.xml :

97,99d96
< <echo message="-------- ${Name-Long} ${component.version} --------"/>
< <filter token="version" value="${component.version}"/>
<
254,256c251
< <mkdir dir="${workdir}/classes"/>
< <mkdir dir="${workdir}/conf"/>
< <copy todir="${workdir}/classes">
---
> <copy todir="${workdir}">
261,263d255
< <copy todir="${workdir}/conf" filtering="on">
< <fileset dir="${source.src}/conf" includes="*.MF"/>
< </copy>
268c260
< <jar jarfile="${dest.jardir.jar}"
manifest="${workdir}/conf/MANIFEST.MF">
---
> <jar jarfile="${dest.jardir.jar}"
manifest="${source.src}/conf/MANIFEST.MF">
17 years, 19 weeks, 1 day ago 18954 No Perforce job exists for this issue. 0 10686 164664 0|i0sjo7:
Commons Collections COLLECTIONS-35

[collections] IteratorChain.hasNext() throws when chain is empty

Bug Closed Major Fixed Unassigned Phil Steitz Phil Steitz 08/Nov/03 12:22   15/Mar/08 21:35 14/Jul/06 12:05 Nightly Builds       1 0   Operating System: other
Platform: Other
If added to TestIteratorChain, the following test case fails with the stack
trace that follows. The exception is documented in the javadoc for
IteratorChain.hasNext(), but the behavior may be inconsistent with the Iterator
interface spec.

Test case:

public void testEmptyChainHasNext() {
IteratorChain chain = new IteratorChain();
assertTrue(!chain.hasNext());
}

Stack trace:

[java] Time: 20.733
[java] There was 1 error:
[java] 1)
testEmptyChainHasNext(org.apache.commons.collections.iterators.TestIteratorChain)
java.lang.UnsupportedOperationException: IteratorChains must contain at least
one Iterator
[java] at
org.apache.commons.collections.iterators.IteratorChain.checkChainIntegrity(IteratorChain.java:248)
[java] at
org.apache.commons.collections.iterators.IteratorChain.lockChain(IteratorChain.java:256)
[java] at
org.apache.commons.collections.iterators.IteratorChain.hasNext(IteratorChain.java:295)
[java] at
org.apache.commons.collections.iterators.TestIteratorChain.testEmptyChainHasNext(TestIteratorChain.java:186)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
13 years, 37 weeks, 4 days ago 18963 No Perforce job exists for this issue. 0 24520 164673 0|i0sjq7:
Commons Collections COLLECTIONS-714

PatriciaTrie ignores trailing null characters in keys

Bug Open Critical Unresolved Unassigned Rohan Padhye Rohan Padhye 30/Apr/19 23:11 18/Mar/20 02:34 04/Nov/19 06:38   4.3   Collection, Map   0 4 0 1800   In Java, strings are not null terminated. The string "x" (of length = 1 char) is different from the string "x\u0000" (of length = 2 chars). However, PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
public void testNullTerminatedKey1() {
Map<String, Integer> map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u0000", 1); // key of length 2
map.put("x\u0000y", 2); // key of length 3
Assert.assertEquals(3, map.size()); // ok, 3 distinct keys

PatriciaTrie<Integer> trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size()); // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u0000" and "x\u0000y". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie<Integer> trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u0000", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key "x\u0000" is inserted.

The PatriciaTrie docs do not mention anything about null-terminated strings. In general, I believe this also breaks the JDK Map contract since the keys "x".equals("x\u0000") is false. 

This bug was found automatically using JQF: [https://github.com/rohanpadhye/jqf].

 
100% 100% 1800 0
20 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 https://github.com/apache/commons-collections/pull/78 0|z02alk:
Commons Collections COLLECTIONS-697

JavaDoc for FixedSizeList should warn that modifying underlying list is still allowed and is not prevented

Bug Resolved Major Fixed Unassigned Ranjan George Ranjan George 02/Oct/18 17:33 18/Mar/20 02:59 11/Jan/20 23:54 11/Jan/20 23:42 4.4 4.5     0 2   I just noticed that it is not explicitly mentioned in the JavaDoc that modifying the underlying list of a FixedSizeList would actually land up modifying the list of the constructed FixedSizeList. Not sure if this was by design, but at the very list I think the JavaDoc should caution against this.

Following is a test case that written that you could use to check this.

{code:java}

public void testAllowsMutationOfUnderlyingCollection() {

List<String> decoratedList = new ArrayList<>();
decoratedList.add("item 1");
decoratedList.add("item 2");
//
FixedSizeList<String> fixedSizeList = FixedSizeList.fixedSizeList(decoratedList);
int sizeBefore = fixedSizeList.size();
//
boolean changed = decoratedList.add("New Value");
Assert.assertTrue(changed);
//
Assert.assertEquals("Modifying an the underlying list is allowed", sizeBefore + 1, fixedSizeList.size());
}

{code}
9 weeks, 3 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3yqvb:
Commons Collections COLLECTIONS-747

MultiKey.getKeys class cast exception

Bug Resolved Major Fixed Gary D. Gregory Walter Laan Walter Laan 10/Feb/20 14:49   17/Feb/20 09:00 16/Feb/20 21:28 4.4 4.5 KeyValue   0 2   When using an non-array constructor of MultiKey, an Object[] is created, which cannot be cast to a K[]
{code}
import org.apache.commons.collections4.keyvalue.MultiKey;

public class MultiKeyClassCastException {

public static void main(String[] args) {
MultiKeyClassCastException key1 = new MultiKeyClassCastException();
MultiKeyClassCastException key2 = new MultiKeyClassCastException();
MultiKeyClassCastException[] keys = new MultiKey<>(key1, key2).getKeys();
}
}

// running gives (same error if in module):

Exception in thread "main" java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast to class [LMultiKeyClassCastException; ([Ljava.lang.Object; is in module java.base of loader 'bootstrap'; [LMultiKeyClassCastException; is in unnamed module of loader 'app')
at MultiKeyClassCastException.main(MultiKeyClassCastException.java:8)
{code}

AFAIK, the only way to fix this (with source compatibility), is to only have a varargs constructors. but I think this breaks binary compatibility though and cannot be used with the existing constructors.
{code}
@SafeVarargs
public MultiKey(K... keys) {
this.keys = keys;
}
{code}

Workaround is to use array constructor with correct typed array or {code}Object[] keys = multiKey.getKeys();{code} explicitly.
4 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z0bbwg:
Commons Collections COLLECTIONS-741

Signature of IteratorUtils.objectGraphIterator is wrong

Bug Open Minor Unresolved Unassigned Hans-Peter Stoerr Hans-Peter Stoerr 10/Dec/19 19:30   10/Dec/19 20:12   4.4       0 1   With the current signature

Iterator<E> objectGraphIterator(E root, Transformer<? super E,? extends E> transformer)

it is impossible to create any other iterator than an Iterator<Object> since the signature for the transformer just doesn't fit. (This problem extends to the underlying [ObjectGraphIterator|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/iterators/ObjectGraphIterator.html], too.) In the [example from the javadoc|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/IteratorUtils.html#objectGraphIterator-E-org.apache.commons.collections4.Transformer-], you would want to return an Iterator<Leaf>, but the root is of type Forest (compare the full source in the [ObjectGraphIteratorTest|https://git-wip-us.apache.org/repos/asf?p=commons-collections.git;a=blob;f=src/test/java/org/apache/commons/collections4/iterators/ObjectGraphIteratorTest.java;h=caff4ed312400c2a9e397c55edff2a5839981a68;hb=HEAD] ), the transformer takes either Forest, Tree, Branch or Leaf as argument and returns Leaf or Iterators of Tree, Branch or Leaf. There just is no common bound for these types except Object. I'm afraid there is no way to get some type safety into this signature. So I suggest to just relax it to

public static <E> Iterator<E> objectGraphIterator(final Object root, final Transformer<Object, Object> transformer)

since Object is the bound for all those arguments, anyway. (In many cases you would have the root and the first type variable the same type E, but the second type variable of the transformer would have to allow for both E and Iterator<E>, and thus be Object. So I'm not sure whether it makes any sense to make any restriction here.)

BTW: While that function has been useful for me, I'm a bit unhappy with it, anyway, since I see no acceptable way to use it to return all nodes of a tree, including the inner nodes, with it. At least not without serious hacks like wrapping the returned nodes in an Object[1] array and chain that to the children iterator.
14 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z09j88:
Commons Collections COLLECTIONS-727

A potential misleading comment

Bug Closed Major Fixed Unassigned XiangzheXu XiangzheXu 20/Aug/19 15:20   23/Aug/19 20:17 23/Aug/19 20:15 4.4 4.5 Iterator   0 2 300 300 0% I was wondering whether there's something wrong in the @throws IndexOutOfBoundsException condition for the `setIterator(final int index, final Iterator<? extends E> iterator)` method in the class `org.apache.commons.collections4.iterators.CollatingIterator<E>`.

The method and its Javadoc comment are shown as follows.



/**
* Sets the iterator at the given index.
*
* @param index index of the Iterator to replace
* @param iterator Iterator to place at the given index
* @throws IndexOutOfBoundsException if index &lt; 0 or index &gt; size()
* @throws IllegalStateException if iteration has started
* @throws NullPointerException if the iterator is null
*/
public void setIterator(final int index, final Iterator<? extends E> iterator) {
checkNotStarted();
if (iterator == null) {
throw new NullPointerException("Iterator must not be null");
}
iterators.set(index, iterator);
}



The boundary of the parameter index is marked as `index &lt; 0 or index &gt; size()`
in the comment.
Nevertheless, the `set(index, iterator)` method would throw an IndexOutOfBoundsException when the index is equal to `size()`.
So it would be better if we could change the boundary in the comment to `index &lt; 0 or index &gt;= size()`.
0% 0% 300 300 JavaDoc
29 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z05ubs:
Commons Collections COLLECTIONS-756

CollectionUtils.filter(..) broken with blank Collections.singleton

Bug Closed Major Not A Problem Unassigned noname713705 noname713705 08/Mar/20 22:20 18/Mar/20 02:47 08/Mar/20 23:29 08/Mar/20 23:29 4.4   Collection   0 1   When using {{CollectionUtils.filter(..)}}, if the passed collection is initialized with jdk {{Collections.singleton(..)}} and only contains an {{isBlank(..)}} string, the method will throw an exception instead of removing blank item as expected. Tested with commons-collections:4.4 and java8.

All can be resumed with
{code:java}
CollectionUtils.filter(Collections.singleton(" "), StringUtils::isNotBlank); {code}
1 week, 2 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z0cb60:
Commons Collections COLLECTIONS-603

Small improvements for generics, conditional statements, and warnings suppressions

Bug Resolved Minor Fixed Bruno P. Kinoshita Bruno P. Kinoshita Bruno P. Kinoshita 24/May/17 08:02   24/May/17 08:21 24/May/17 08:21   4.2 Collection   0 1   Place holder for pull request #17 2 years, 42 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807
Patch
0|i3fe67:
Commons Collections COLLECTIONS-602

Improve efficiency of DefaultedMap.get

Bug Resolved Major Fixed Bruno P. Kinoshita John Mark John Mark 19/May/17 14:23   24/May/17 09:35 24/May/17 09:35   4.2     0 2   The current implementation of {{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient since it always require two map lookups. There is no need to check map.containsKey() every time. I would suggest implementing this method similar to the way that Java 8 does with {{Map.getOrDefault()}}. My proposed implementation would be something like this:

{code}
public V get(final Object key) {
V v;
return ((v = map.get(key) != null) || map.containsKey(key)) ? v : value.transform((K) key);
}
{code}

It can be further optimized to not even call map.containsKey() if map is known to not contain null values.
help-wanted 2 years, 42 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807 0|i3f84f:
Commons Collections COLLECTIONS-679

MultiValuedMap JavaDoc Typo

Bug Resolved Trivial Fixed Unassigned David Mollitor David Mollitor 16/Mar/18 19:02   25/Sep/19 14:47 25/Sep/19 14:47   4.5     0 2 0 1200   https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35

The example code provided refers to a class called _MultiValuedHashMap_. There is no such class in Commons Collection4. Perhaps _ArrayListValuedHashMap_ is a better example.
100% 100% 1200 0
24 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3rf87:
Commons Collections COLLECTIONS-662

Build failures when building with Java 9

Bug Resolved Major Fixed Pascal Schumacher Vamsi Vamsi 12/Oct/17 04:12   20/Oct/17 16:33 20/Oct/17 14:09         0 4   *mvn clean test* fails with following errors when using with java-9
{code:java}
Tests in error:
MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration sun.util.locale.prov...
MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration sun.util.locale.pro...
MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration sun.util.locale.prov...
MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration sun.util.locale.provi...
MapUtilsTest.testgetLongValue:992 » ServiceConfiguration sun.util.locale.provi...
MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration sun.util.locale.pro...
ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration sun.util.locale....

Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
{code}
2 years, 21 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3l60v:
Commons Collections COLLECTIONS-685

IterableUtils has public constructor

Bug Open Trivial Unresolved Unassigned Stephan Fuhrmann Stephan Fuhrmann 12/Jun/18 06:04   12/Jun/18 21:48     5.0 Collection   0 4   IterableUtils has public constructor. All other Utils classes have their constructor made private to prohibit instantiation.
1 year, 40 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3urb3:
Commons Collections COLLECTIONS-716

Don't include email address in Exception messages

Bug Closed Major Fixed Unassigned Sebb Sebb 12/May/19 12:42   05/Jul/19 15:26 05/Jul/19 15:26   4.4     0 0   There are several messages in LRUMap which reference dev@commons.

These need to be replaced, see:

https://lists.apache.org/thread.html/5c3805daf30768034ae18576b7275b0535b4e5aec839cd13de2103c1@%3Cdev.commons.apache.org%3E
36 weeks, 4 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z02lz4:
Commons Collections COLLECTIONS-683

README.md contains pointer to non-existing Maven artifact/javadoc

Bug Open Minor Unresolved Unassigned Stephan Fuhrmann Stephan Fuhrmann 11/Jun/18 16:47   13/Jun/18 08:12           0 2   The README.md file contains references to the
* 4.2 maven artefact on maven central (see XML snippet)
* 4.2 Javadoc on javadoc.io (see badge)

These pointers do not exist and confuse the developers.

The current version in fact is 4.1.

 

 

 
1 year, 40 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3uqj3:
Commons Collections COLLECTIONS-682

README.md contains unresolved template references

Bug Closed Trivial Fixed Unassigned Stephan Fuhrmann Stephan Fuhrmann 11/Jun/18 16:43   12/Jun/18 21:40 11/Jun/18 22:51   4.2     0 1   https://github.com/apache/commons-collections/blob/master/README.md The README.md file contains an unresolved reference to

{{${project.description}}}

 
1 year, 40 weeks ago 9223372036854775807 No Perforce job exists for this issue. 1 9223372036854775807 0|i3uqi7:
Commons Collections COLLECTIONS-680

CollectionUtilsTest test for collect is broken

Bug Resolved Major Fixed Unassigned Konstantinos Angelopoulos Konstantinos Angelopoulos 24/Apr/18 15:08   12/Jun/18 21:50 12/Jun/18 21:50     Collection   0 2   Cannot resolve method ConnectionUtils.collect in line 1289.
1 year, 40 weeks ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3syjb:
Commons Collections COLLECTIONS-686

Coveralls.io set to wrong branch?

Bug Open Trivial Unresolved Unassigned Stephan Fuhrmann Stephan Fuhrmann 13/Jun/18 17:40   13/Jun/18 17:40           0 1   [https://coveralls.io/github/apache/commons-collections?branch=master]

[https://coveralls.io/github/apache/commons-collections]

 
According to

[https://coveralls.io/github/apache/commons-collections]

the default branch is *trunk* and has 85% coverage (last commit June 2017). But the real working github branch is *master* and has 87% coverage.

This is why the coveralls badge on Github shows 85% I guess. I suggest switching the default branch on coveralls from trunk to master.

 

 
1 year, 39 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3utqn:
Commons Collections COLLECTIONS-663

Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

Bug Open Trivial Unresolved Bruno P. Kinoshita Christophe Schmaltz Christophe Schmaltz 04/Nov/17 17:38   06/Nov/19 07:23           0 4 0 600   Testcase:
{code} @Test
public void test() {
MultiValuedMap<Integer, Integer> multiMap = new HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection<Integer> innerCollection : multiMap.asMap().values()) {
for (Iterator<Integer> iterator = innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection is altered
}
// innerCollection.add(6); // adding stuff back should also work...
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It may be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead.
*Note:* this solution would again present issues if the user tries to add new elements in this now empty collection (which was removed from the parent).


In the current state, it is quite unclear why an exception is thrown, without debugging the code.
100% 100% 600 0
18 weeks, 6 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i3meo7:
Commons Collections COLLECTIONS-732

Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()

Bug Open Major Unresolved Unassigned Chen Chen 05/Nov/19 12:36 18/Mar/20 02:46 18/Jan/20 08:47       Map   0 2   copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap<String, String> listMap = new ArrayListValuedHashMap<>();
List<String> listA = listMap.get("A");
listA.addAll(0, Arrays.asList("W", "X", "F"));
List<String> listB = listMap.get("B");
listB.addAll(0, Arrays.asList("Q", "Q", "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());

for(MapIterator<String, String> iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
String value = iterator.getValue();
if(value == "F"){
iterator.setValue("B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
It throws an UnsupportedOperationException when altering mapIterator().setValue()。
I found UnsupportedOperationException is thrown in the code of setValue。So,if setValue method is not supported,the Javadoc should comment it。
8 weeks, 3 days ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|z089tk:
Commons Collections COLLECTIONS-445

Several unit test failures with IBM JDK 6

Bug Closed Blocker Fixed Unassigned Thomas Neidhart Thomas Neidhart 26/Feb/13 21:21   09/Nov/14 14:31 21/Apr/13 17:48   4.0-alpha1, 4.0     0 0   Failed tests:
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value, value, seev, tmpv, we'llv, youv] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapKeySet>AbstractCollectionTest.testCollectionRemove:881 Collection should remove extant element: key
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again>
AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<again>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
DualTreeBidiMapTest>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<againv>
AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value, value2, seev, tmpv, we'llv, youv] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you>
AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<you>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
DualTreeBidiMap2Test>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<youv>
AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [foov] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [againv, allv, barv, bazv, blahv, foov] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>

Tests in error:
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
6 years, 48 weeks, 2 days ago 314784 No Perforce job exists for this issue. 1 315128 0|i1ibjb:
Commons Collections COLLECTIONS-408

performance problem in SetUniqueList.removeAll()

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 02/Jun/12 06:56   09/Nov/14 14:31 19/Jun/12 19:22   4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in SetUniqueList.removeAll().
It appears in version 3.2.1 and also in revision 1344775 (31 May
2012). I have attached a test that exposes this problem and a
one-line patch that fixes it. The patch makes the code two times
faster for this test.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is: 5027

The output for the patched version is:
Time is: 2554

The one-line patch I attached changes the
SetUniqueList.removeAll(Collection<?> coll) code from:

boolean result = super.removeAll(coll);
set.removeAll(coll);
return result;

to:

boolean result = super.removeAll(coll);
if (result) set.removeAll(coll);
return result;

If "super.removeAll(coll)" did not change the collection, there is no
need to call "set.removeAll(coll)", because we already know there is
nothing to remove.

As one may expect "set.removeAll(coll)" (on a set) to be faster than
"super.removeAll(coll)" (on a list), one may have expected the speedup
gained by avoiding "set.removeAll(coll)" to be smaller than 2X
achieved for the attached test. However, the speedup is 2X because
"java.util.HashSet.removeAll(Collection<?> collection)" has quadratic
(not linear) complexity if "this.size() <= collection.size()" and the
"collection" is a list. Thus, "set.removeAll(coll)" is about as slow
as "super.removeAll(coll)" in this case, and not executing
"set.removeAll(coll)" reduces the work done by half. The quadratic
behavior of "java.util.HashSet.removeAll(Collection<?> collection)"
comes from "java.util.AbstractSet.removeAll(Collection<?> c)" and is
discussed for example here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007148.html
(The link is for OpenJDK, but Oracle JDK has the same problem.)

In many other cases "set.removeAll(coll)" is actually faster than
"super.removeAll(coll)", so one can get even more speedup by
reordering those two checks:

boolean result = set.removeAll(coll);
if (result) super.removeAll(coll);
return result;

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

7 years, 40 weeks ago 292950 No Perforce job exists for this issue. 2 164352 0|i0shqv:
Commons Collections COLLECTIONS-473

AbstractCollectionDecorator.decorated() should not be used internally

Bug Closed Major Fixed Unassigned Sebb Sebb 17/Jun/13 22:17   09/Nov/14 14:31 18/Jun/13 20:29   4.0-alpha1, 4.0     0 0   AbstractCollectionDecorator.decorated() is used internally to access the collection.
However, the method is not final, so subclasses could override it.

Yet the field is also exposed (protected).

This is inconsistent.

Is there any use-case for overriding the collection to use a different one?
If so, having direct access as well is likely to cause problems.

I think it would be better to use the field directly internally.
The class Javadoc says the calls are forwarded to the underlying collection, but that is not strictly true if decorated() is overridden.

If it is intended to allow this to be overridden, then the field needs to be protected against arbitrary read/write access.

The field should probably be made private with a setter for use by deserialization only.
6 years, 40 weeks ago 333609 No Perforce job exists for this issue. 0 333937 0|i1ljsn:
Commons Collections COLLECTIONS-468

Change Bag interface and implementations to conform to Collection interface

Bug Closed Major Fixed Unassigned Thomas Neidhart Thomas Neidhart 13/May/13 20:57   09/Nov/14 14:31 17/Jun/13 21:06   4.0-alpha1, 4.0     0 1   Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll).
This should be fixed for 4.0.
6 years, 37 weeks, 4 days ago 327730 No Perforce job exists for this issue. 3 328074 0|i1kjnz:
Commons Collections COLLECTIONS-461

splitmap.TransformedMap is not really a Map

Bug Closed Major Fixed Unassigned Sebb Sebb 06/May/13 10:16   09/Nov/14 14:31 14/May/13 20:02   4.0-alpha1, 4.0     0 1   splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not behave like a proper Java Map.

In particular, java.util.Map.put(K, V) returns V.
However the collections Put interface returns Object.
As far as I can tell, this was done in order to be able to include TransformedMap in the hiearchy. But the side effect is to break the generics for all the non-transformer maps in the hierarchy.

Maybe there should be a separate PutTransformed interface which has the appropriate generic types, i.e.

public T put(K key, V value)

6 years, 45 weeks ago 326546 No Perforce job exists for this issue. 0 326891 0|i1kc3b:
Commons Collections COLLECTIONS-458

AbstractUntypedCollectionDecorator<E, D> is not used

Bug Closed Major Fixed Unassigned Sebb Sebb 29/Apr/13 22:20   27/Nov/15 21:11 30/Apr/13 12:00         0 0   The public ctor for AbstractUntypedCollectionDecorator<E, D> takes no argument and so collection = null; however the protected ctor checks for collection parameter != null.

The decorated() method says that all access to collection goes through it, and there is no setter.

At present the only way to recover from calling the public ctor is for the sub-class to set collection directly.

This is inconsistent.

The class is abstract and there appear to be no concrete subclasses. Looks like the class might be superfluous, but if it is required, it should ideally have a private final collection field.
6 years, 47 weeks ago 325684 No Perforce job exists for this issue. 0 326029 0|i1k6rz:
Commons Collections COLLECTIONS-459

ArrayIterator & ObjectArrayIterator - do they need setters?`

Bug Closed Major Fixed Unassigned Sebb Sebb 30/Apr/13 12:15   09/Nov/14 14:31 18/Jun/13 19:35   4.0-alpha1, 4.0     0 0   ArrayIterator & ObjectArrayIterator both have methods to set the array separately from the ctor.

However the method does not allow the same flexibility as the ctor, as it does not allow the start or end indexes to be set.

Is there really a use-case for these setters? If not, all the fields apart from index could be made final, which would make thread safety (and testing) easier.
6 years, 40 weeks ago 325781 No Perforce job exists for this issue. 0 326126 0|i1k7dj:
Commons Collections COLLECTIONS-455

AbstractDualBidiMap<K, V> has several mutable protected fields

Bug Closed Major Fixed Unassigned Sebb Sebb 29/Apr/13 00:05   09/Nov/14 14:31 18/Jun/13 20:55   4.0-alpha1, 4.0     0 0   Any non-private mutable fields make it much harder to ensure thread-safety as well as making it very difficult to test thoroughly.

The fields should be made private.
If protected write access really is needed, setter methods should be used.
These methods can take any necessary precautions to ensure thread-safety.
6 years, 40 weeks ago 325480 No Perforce job exists for this issue. 0 325825 0|i1k5in:
Commons Collections COLLECTIONS-588

Redundant computation in CollectionBag and CollectionSortedBag

Bug Open Major Unresolved Unassigned Monika Dhok Monika Dhok 02/May/16 16:18   12/Jan/20 00:47           0 2   There appears to be redundant computations in "CollectionBag.retainAll"
method in the version 4.4.1. I have attached a test and proposed a small
patch which ensures that "contains" method is called on hashset of
input collection. This patch gives 892X speed up on my
machine for the provided test.
Similar patches can be applied for, "CollectionSortedBag.retainAll".
9 weeks, 3 days ago 9223372036854775807 No Perforce job exists for this issue. 2 9223372036854775807
Patch
0|i2x1pz:
Commons Collections COLLECTIONS-583

JAVA serialization vulnerability "CVE-2015-4852" in commons-collections*.jar

Bug Resolved Major Duplicate Unassigned Arnoj Saha Arnoj Saha 14/Dec/15 07:02   14/Dec/15 07:47 14/Dec/15 07:47   3.2.2, 4.1     0 2   The vulnerability we are talking about is known under number CVE-2015-4852. As far as we know this is only related to the

file commons-collections*.jar. In this jar file is a class that takes care of the deserialization.

Currently we are using commons-collections-3.2.1.jar.
Is there a version of this jar that does not have this vulnerability?
4 years, 14 weeks, 1 day ago 9223372036854775807 No Perforce job exists for this issue. 0 9223372036854775807 0|i2pucf:
Commons Collections COLLECTIONS-438

ExtendedProperties : String only composed of spaces character

Bug Closed Major Invalid Unassigned Guillaume Chauvet Guillaume Chauvet 28/Dec/12 09:00   27/Nov/15 21:47 22/Jan/13 13:56     Collection   0 1   We have discovered a bug in ExtendedProperties class used in our internal language manager framework. The cause are strings which contains only spaces character. We provide a patch to complete the JUnit class ExtendedPropertiesTest.
7 years, 9 weeks, 2 days ago 301949 No Perforce job exists for this issue. 1 248577 0|i16xlr:
Commons Collections COLLECTIONS-437

CollectionUtils.removeAll invoke ListUtils.retainAll !!!

Bug Closed Critical Duplicate Unassigned qxo qxo 26/Dec/12 07:04   09/Nov/14 14:31 28/Feb/13 18:38   4.0-alpha1, 4.0     0 2   public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
7 years, 12 weeks, 3 days ago 301779 No Perforce job exists for this issue. 0 248392 0|i16wgv:
Commons Collections COLLECTIONS-449

Latest Version is set to 20040616

Bug Closed Critical Won't Fix Joerg Schaible Kai Cabuslay Kai Cabuslay 14/Mar/13 02:50   14/Mar/13 07:28 14/Mar/13 07:28         0 2   The current maven metadata file for commons-collections shows that the "latest version" is 20040616. This is currently affecting spring-webmvc (3.1.3-RELEASE) - causing it to use the outdated version of the collections package.

http://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml
7 years, 1 week, 5 days ago 317440 No Perforce job exists for this issue. 0 317781 0|i1irwf:
Commons Collections COLLECTIONS-421

Update JavaDoc in ListUtils to discribe generified methods

Bug Closed Trivial Fixed Unassigned Benedikt Ritter Benedikt Ritter 07/Jul/12 14:47   09/Nov/14 14:31 14/Jul/12 21:36   4.0-alpha1, 4.0 Collection   0 2   The JavaDoc of {{ListUtils.lazyList()}} and {{ListUtils.fixedSizeList}} still refer to the old methods prior to generics. This should be updated. 7 years, 36 weeks, 2 days ago 292942 No Perforce job exists for this issue. 1 164344 0|i0shp3:
Commons Collections COLLECTIONS-412

CollectionUtils.subtract() is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 20/Jun/12 20:44   09/Nov/14 14:31 23/Jun/12 11:34   4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in CollectionUtils.subtract().
It appears in version 3.2.1 and also in revision 1352300 (20 June
2012). I attached a test that exposes this problem and a patch that
fixes it. On my machine, for this test, the patch provides a 204X
speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 11036

The output for the patched version is:
Time is 54

The root cause of this problem is similar to the root cause of the
previously fixed COLLECTIONS-406 in ListUtils.subtract(), i.e.,
quadratic complexity instead of linear complexity. This problem
affects two methods:

CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b)
and
CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p)

because the former just calls the latter.

Currently, the code for
"CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p)"
is:

ArrayList<O> list = new ArrayList<O>();
addAll(list, a);
for (O element : b) {
if (p.evaluate(element)) {
list.remove(element);
}
}

which is quadratic, because "list.remove(element)" has linear
complexity for "ArrayList<O> list = new ArrayList<O>()".

The attached patch makes the remove() be constant complexity by
removing from an org.apache.commons.collections.bag.HashBag. The
attached patch is very similar to the patch of COLLECTIONS-406, so I
assume the risk of applying this patch is minimal. Just like in the
patch for COLLECTIONS-406, this patch uses a HashBag (and not a
HashSet) to respect cardinality when there are repeated objects.

Can you please confirm if the patch is correct?

Thanks,

Adrian

7 years, 39 weeks, 3 days ago 292946 No Perforce job exists for this issue. 2 164348 0|i0shpz:
Commons Collections COLLECTIONS-411

Exception in ListOrderedMap.putAll()

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 20/Jun/12 15:45   09/Nov/14 14:31 20/Jun/12 17:54   4.0-alpha1, 4.0     0 2   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering an IndexOutOfBoundsException in
ListOrderedMap.putAll(int index, Map<? extends K, ? extends V> map).
It appears in revision 1351903 (20 June 2012). I have attached a test
that exposes this problem.

To run the test, just do:

$ java Test

The output is:

......................................................................
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 5, Size: 4
at java.util.ArrayList.add(ArrayList.java:367)
at org.apache.commons.collections.map.ListOrderedMap.put(ListOrderedMap.java:437)
at org.apache.commons.collections.map.ListOrderedMap.putAll(ListOrderedMap.java:245)
at Test.main(Test.java:19)
......................................................................

The documentation does not specify anything like this. Is this a bug,
or should the documentation just be updated? If the former, is there
a patch for it?

Thanks,

Adrian


7 years, 39 weeks, 6 days ago 292947 No Perforce job exists for this issue. 1 164349 0|i0shq7:
Commons Collections COLLECTIONS-410

SetUniqueList.addAll() is very slow

Bug Closed Major Fixed Unassigned Adrian Nistor Adrian Nistor 19/Jun/12 20:37   09/Nov/14 14:31 20/Jun/12 18:04   4.0-alpha1, 4.0     0 3   java 1.6.0_24
Ubuntu 11.10
Hi,

I am encountering a performance problem in SetUniqueList.addAll(). It
appears in revision 1351837 (19 June 2012). I attached a test that
exposes this problem and a patch that fixes it. On my machine, for
this test, the patch provides a 540X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 2706

The output for the patched version is:
Time is 5

As the patch shows, the problem is that
SetUniqueList.addAll(int index, Collection<? extends E> coll)
performs:
"add(index, e)" for each element in "coll". This is very expensive,
because each "add(index, e)" performs a
LinkedList.add(int index, E element), which requires traversing the
LinkedList to find the index.

The patched version avoids this cost by inserting all the elements at
once, thus performing only one insert.

Is this a bug? If so, can you please confirm that the patch is
correct?

Thanks,

Adrian
7 years, 39 weeks, 6 days ago 292948 No Perforce job exists for this issue. 2 164350 0|i0shqf:
Commons Collections COLLECTIONS-527

Please create a version commons-collections 3.x for jdk 8 compatibility

Bug Closed Blocker Won't Fix Unassigned Ignat Alexeyenko Ignat Alexeyenko 15/May/14 10:12   27/Nov/15 21:47 16/May/14 23:00         0 3   Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for these, who implement common's MultiMap.

*Compilation Error*
If anyone implement MultiMap in their code, compilation fails with the error:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with Java 8. For many big project switch to commons-collections 4.x is not an option - some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their internal artifact. Why do it if the official compatibility version can be created?

Thanks!
java8, jdk8
5 years, 44 weeks, 4 days ago 392748 No Perforce job exists for this issue. 1 392924 0|i1vmtr:
Commons Collections COLLECTIONS-521

Typo in MultiMapKey's isEqualKey(entry, key1, key2)

Bug Closed Major Fixed Unassigned Maxime Nay Maxime Nay 01/May/14 20:51   27/Nov/15 21:11 06/May/14 21:38   4.1     0 2   I believe there is a typo line 252 in MultiKeyMap.
return
multi.size() == 2 &&
(key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) &&
(key2 == multi.getKey(1) || key1 != null && key2.equals(multi.getKey(1)));

should be:
return
multi.size() == 2 &&
(key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) &&
(key2 == multi.getKey(1) || key2 != null && key2.equals(multi.getKey(1)));
5 years, 44 weeks, 2 days ago 390113 No Perforce job exists for this issue. 0 390350 0|i1v71r:
Commons Collections COLLECTIONS-332

ListOrderedMap not respecting underlying list

Bug Closed Minor Fixed Unassigned Tom Parker Tom Parker 10/Jul/09 02:24   09/Nov/14 14:31 08/Mar/11 21:34   4.0-alpha1, 4.0 Map   0 1   When decorating either CaseInsensitiveMap or IdentityMap (and I believe this will impact any java.util.TreeMap built with a non-.equals() Comparator), ListOrderedMap responds inconsistently with the underlying map. The ordering seems to be operating off .equals() rather than the actual contents of the underlying map.
9 years, 3 weeks ago 18671 No Perforce job exists for this issue. 1 164409 0|i0si3j:
Commons Collections COLLECTIONS-330

ConcurrentModificationException using remove from the keySet the LRUMap

Bug Closed Major Fixed Unassigned Joerg Schaible Joerg Schaible 17/Jun/09 09:52   09/Nov/14 14:31 21/Feb/11 19:17   4.0-alpha1, 4.0 Collection   0 0   Even if the access to a LRUMap is synced and the remove method of the iterator is used that has been returned from the keySet of the LRUMap, it is possible to get a ConcurrentModificationException. This does not happen for remove of the iterators returned by the entrySet or values of the LRUMap. See currently not executed unit test in TestLRUMap (marked as TODO for COLLECTION-3). 9 years, 5 weeks, 1 day ago 18673 No Perforce job exists for this issue. 0 164411 0|i0si3z:
Commons Collections COLLECTIONS-380

UnmodifiableBoundedCollection.unmodifiableBoundedCollection is an infinite loop

Bug Closed Minor Fixed Unassigned Dave Brosius Dave Brosius 29/Sep/11 18:45   09/Nov/14 14:31 09/Apr/12 18:41   4.0-alpha1, 4.0 Collection   0 0   This method, just calls itself. As BoundedCollection extends Collection, it would seem to me that this method should be removed:


/**
* Factory method to create an unmodifiable bounded collection.
*
* @param coll the <code>BoundedCollection</code> to decorate, must not be null
* @return a new unmodifiable bounded collection
* @throws IllegalArgumentException if bag is null
*/
public static <E> BoundedCollection<E> unmodifiableBoundedCollection(BoundedCollection<E> coll) {
return unmodifiableBoundedCollection(coll);
}
7 years, 50 weeks, 1 day ago 40352 No Perforce job exists for this issue. 0 164374 0|i0shvr:
Commons Collections COLLECTIONS-364

DualTreeBidiMap.readObject() uses wrong comparator to create reverseMap

Bug Closed Major Fixed Sebb Sebb Sebb 18/Oct/10 18:51   27/Nov/15 21:11 18/Oct/10 19:17     BidiMap   0 0   DualTreeBidiMap.readObject() uses the wrong comparator to create reverseMap. The code reads:

bq. reverseMap = new TreeMap(comparator);

it should read:

bq. reverseMap = new TreeMap(valueComparator);

Note: this was found when trying to fix generics warnings.
9 years, 23 weeks, 1 day ago 18639 No Perforce job exists for this issue. 0 164384 0|i0shxz:
Commons Collections COLLECTIONS-378

Incorrect links in JavaDoc

Bug Closed Major Implemented Unassigned Ken Dombeck Ken Dombeck 08/Aug/11 16:54   09/Nov/14 14:31 28/Feb/13 19:17   4.0-alpha1, 4.0     0 0   The links for several JavaDocs were not updated during the implementation of COLLECTIONS-251.

Attached patch file includes the necessary changes.
7 years, 50 weeks, 1 day ago 18625 No Perforce job exists for this issue. 1 164376 0|i0shw7:
Commons Collections COLLECTIONS-340

NOPClosure has a broken equals method

Bug Closed Minor Fixed Unassigned Goran Hacek Goran Hacek 14/Oct/09 11:45   09/Nov/14 14:31 28/Feb/13 19:55   4.0-alpha1, 4.0 Functor   0 0   Equals method of NOPClosure class doesn't follow objects equals contract. It isn't symmetric nor transitive and it is just plain wrong.

Following code evaluates to true on most (if not all) JVM implementations:
{noformat} NOPClosure.INSTANCE.equals(new Integer(System.identityHashCode(NOPClosure.INSTANCE))) {noformat}
6 years, 48 weeks ago 18663 No Perforce job exists for this issue. 0 164402 0|i0si1z:
Commons Collections COLLECTIONS-334

map.StaticBucketMap.size() needs to synchronize access to lock

Bug Closed Major Fixed Jochen Wiedmann Sebb Sebb 11/Sep/09 17:46   08/Nov/15 21:07 01/Mar/11 22:36   3.2.2, 4.0-alpha1, 4.0 Collection   0 0   collections_jdk5_branch The field Lock.size is updated using synchronization, however the StaticBucketMap.size() method reads the values without synch.

If the read is done in a different thread from the updates, there is no guarantee that the reading thread will see the most recent value.
9 years, 4 weeks ago 18669 No Perforce job exists for this issue. 0 164408 0|i0si3b:
Commons Collections COLLECTIONS-343

Functor singleton classes do not implement singleton pattern correctly

Bug Closed Major Fixed Unassigned Goran Hacek Goran Hacek 15/Oct/09 12:15   09/Nov/14 14:31 28/Feb/13 19:37   4.0-alpha1, 4.0 Functor   0 0   All classes in package "org.apache.commons.collections.functors" that advertise that they have singleton instance actually cannot guarantee that. Because of serialization support multiple instances of those classes can exist at runtime.

Following classes are making this false claim:
* CloneTransformer
* ExceptionClosure
* ExceptionFactory
* ExceptionPredicate
* ExceptionTransformer
* FalsePredicate
* NOPClosure
* NOPTransformer
* NotNullPredicate
* NullPredicate
* StringValueTransformer
* TruePredicate
10 years, 13 weeks ago 18660 No Perforce job exists for this issue. 1 164400 0|i0si1j:
Commons Collections COLLECTIONS-335

bidimap.TreeBidiMap.entrySet is never written

Bug Closed Major Fixed Jochen Wiedmann Sebb Sebb 11/Sep/09 22:17   07/Nov/15 20:31 01/Mar/11 22:28   3.2.2, 4.0-alpha1, 4.0     0 0   The field bidimap.TreeBidiMap.entrySet is never written.

Looks like it was perhaps intended to be used as a cache, but the cache value is not written.
9 years, 4 weeks ago 18668 No Perforce job exists for this issue. 0 164407 0|i0si33:
Commons Collections COLLECTIONS-337

BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names

Bug Closed Major Won't Fix Unassigned Sebb Sebb 15/Sep/09 19:32   19/Jun/10 19:43 19/Jun/10 19:43         0 0   BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names - they are the same as the JUnit names, but don't override them.

Of course it's still possible to use the JUnit versions of the methods, but the code is harder to understand.
9 years, 40 weeks, 3 days ago 18666 No Perforce job exists for this issue. 0 164405 0|i0si2n:
Commons Collections COLLECTIONS-299

ExtendedProperties.convertProperties loses non-String values

Bug Closed Major Fixed Unassigned Simon Kitching Simon Kitching 16/Jun/08 11:13   27/Nov/15 21:11 28/Feb/13 19:37     Core   0 0   A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.

ExtendedProperties.convertProperties does this:
{code}
for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
String s = (String) e.nextElement();
c.setProperty(s, props.getProperty(s));
}
{code}

Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.

It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.

Perhaps the call
props.getProperty(s)
can be changed to
props.get(s)

Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.
6 years, 48 weeks ago 18702 No Perforce job exists for this issue. 0 164434 0|i0si93:
Commons Collections COLLECTIONS-321

ComparableComparator.getInstance() not compilable with jdk-compiler

Bug Closed Major Fixed Unassigned Daniel Golesny Daniel Golesny 24/Feb/09 11:10   09/Nov/14 14:31 28/Feb/13 20:24   4.0-alpha1, 4.0 Comparator   0 1   Comparator<Integer> c = ComparableComparator.getInstance();

This line is valid with eclipse (3.4) compiler, but the jdk 1.5.0 compiler returns this error:
[javac] J:\workspace\ndt\cobolclipse-TRUNK\collections_jdk5_branch\src\java\org\apache\commons\collections\comparators\ComparableComparatorTest.java:23: incompatible types; no instance(s) of type variable(s) E exist so that org.apache.commons.collections.comparators.ComparableComparator<E> conforms to java.util.Comparator<java.lang.Integer>
[javac] found : <E>org.apache.commons.collections.comparators.ComparableComparator<E>
[javac] required: java.util.Comparator<java.lang.Integer>
[javac] Comparator<Integer> c = ComparableComparator.getInstance();
[javac] ^
[javac] 1 error
10 years, 28 weeks, 4 days ago 18680 No Perforce job exists for this issue. 0 164416 0|i0si53:
Commons Collections COLLECTIONS-320

StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator

Bug Closed Minor Fixed Unassigned Sebb Sebb 16/Feb/09 21:58   09/Nov/14 14:31 28/Feb/13 19:58   4.0-alpha1, 4.0 Map   0 0   StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator.

Patch to follow.
10 years, 48 weeks, 6 days ago 18681 No Perforce job exists for this issue. 1 164417 0|i0si5b:
Commons Collections COLLECTIONS-319

IteratorUtils.getIterator(Object obj) performs redundant null check

Bug Closed Minor Fixed Unassigned Sebb Sebb 16/Feb/09 19:35   09/Nov/14 14:31 28/Feb/13 20:24   4.0-alpha1, 4.0 Collection   0 0   IteratorUtils.getIterator(Object obj) performs redundant null check:

{code}
if (obj == null) {
return emptyIterator();
...
} else if (obj != null && obj.getClass().isArray()) {
return new ArrayIterator(obj);
{code}

obj cannot be null at that point, so the check can be removed.
[This will also prevent a false positive in Eclipse which later says tha obj may be null]
10 years, 48 weeks, 6 days ago 18682 No Perforce job exists for this issue. 0 164418 0|i0si5j:
Commons Collections COLLECTIONS-318

CollectionUtils.size(Object object) has impossible null check

Bug Closed Minor Fixed Unassigned Sebb Sebb 16/Feb/09 19:28   09/Nov/14 14:31 28/Feb/13 19:58   4.0-alpha1, 4.0 Collection   0 0   CollectionUtils.size(Object object) has impossible null check:

{code}
public static int size(Object object) {
if (object == null) {
return 0;
}
...
} else if (object == null) {
throw new IllegalArgumentException("Unsupported object type: null");
...
{code}

The Javadoc specifically says that null is allowed, so I think the object == null clause needs to be removed - it can never be true, and is just confusing.
10 years, 48 weeks, 6 days ago 18683 No Perforce job exists for this issue. 0 164419 0|i0si5r:
Commons Collections COLLECTIONS-317

AbstractHashedMap(Map map) constructor calls overridable non-final method

Bug Closed Minor Fixed Unassigned Sebb Sebb 16/Feb/09 16:18   09/Nov/14 14:31 28/Feb/13 20:04   4.0-alpha1, 4.0 Map   0 0   The constructor AbstractHashedMap(Map map) calls the public non-final method putAll() from the same class.

This is likely to cause problems if the method is ever overridden, as the parent may not have been completely initialised when the sub-class method is invoked.

Possible solution: extract the code into a common private method. Or make the method final.

10 years, 44 weeks, 6 days ago 18684 No Perforce job exists for this issue. 0 164420 0|i0si5z:
Commons Collections COLLECTIONS-288

Javadoc: incorrect behavior explained for ListUtils.transformedList

Bug Closed Major Fixed Unassigned Paul Benedict Paul Benedict 17/Mar/08 16:34   09/Nov/14 14:31 28/Feb/13 19:38   4.0-alpha1, 4.0 List   0 0   The contract stated for ListUtils.transformedList is wrong. The list is not transformed -- it decorates the existing list and transforms NEW objects -- EXISTING objects are not transformed.

Compare this to the javadoc found in MapUtils.transformedMap:
"This method returns a new map (decorating the specified map) that will transform any new entries added to it. Existing entries in the specified map will not be transformed. "

That little missing piece of information messed me up. Just replace "map" with "list" and append it to the existing LilstUtils javadoc.
12 years, 2 weeks ago 18712 No Perforce job exists for this issue. 0 164442 0|i0siav:
Commons Collections COLLECTIONS-45

[collections] ReferenceMap size of bug.

Bug Closed Critical Cannot Reproduce Unassigned emily emily 16/Feb/06 04:26   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: PC
I have the following declaration of my map:

Here is the code:
System.err.println("elements are " + elements + "\n\t element size is " +
elements.size() + "\n\tkey set " + elements.keySet() + "\n\telements:" +
elements.values());
Iterator iter = elements.keySet().iterator();
while (iter.hasNext()) {
Object element = iter.next();
System.err.println("next element:" + element);
}
System.err.println("--------------");
Here is the results below, where usually the answer is 2 but occationally 3


elements are {Concept=ConceptImpl Concept, ValueSet=ConceptImpl ValueSet}
element size is 3
key set [Concept, ValueSet]
elements:[ConceptImpl Concept, ConceptImpl ValueSet]
next element:Concept
next element:ValueSet
--------------
size:3
14 years, 4 weeks, 4 days ago 18953 No Perforce job exists for this issue. 0 38661 164663 0|i0sjnz:
Commons Collections COLLECTIONS-13

[collections] Typo in user documentation

Bug Closed Trivial Fixed Unassigned Chad McHenry Chad McHenry 17/Jan/05 07:34   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: All
Platform: All
Will attach patch momentarily.
15 years, 8 weeks, 4 days ago 18985 No Perforce job exists for this issue. 1 33125 164695 0|i0sjv3:
Commons Collections COLLECTIONS-7

[collections] BlockingBuffer waits/notifies wrong Object?

Bug Closed Major Fixed Unassigned Sebb Sebb 12/Oct/05 04:22   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
The code contains various examples of the form:

synchronized (lock) {
...
notifyAll();
}

which should probably be:

synchronized (lock) {
...
lock.notifyAll();
}

Patch to follow
14 years, 24 weeks, 3 days ago 18991 No Perforce job exists for this issue. 1 37028 164701 0|i0sjwf:
Commons Collections COLLECTIONS-121

[Collections] Improvements to maven build

Bug Closed Major Fixed Unassigned Carlos Sanchez Gonzalez Carlos Sanchez Gonzalez 11/Oct/05 08:07   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
Improvements to project.xml updating deprecated tags and making it easier for
maven 2 users.
14 years, 25 weeks ago 18877 No Perforce job exists for this issue. 1 37012 164587 0|i0sj73:
Commons Collections COLLECTIONS-43

[collections] serialVersionUID should be private

Bug Closed Minor Fixed Unassigned Sebb Sebb 17/Oct/05 04:03   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
The following classes define serialVersionUID with default (package) access:

HashBag
TreeBag
functors.*
NodeCachingLinkedList
LRUMap

This field should be defined as private.
14 years, 18 weeks, 6 days ago 18955 No Perforce job exists for this issue. 0 37106 164665 0|i0sjof:
Commons Collections COLLECTIONS-127

[collections] Strong reference not really cleared in TestReference*Map testcases

Bug Closed Major Fixed Unassigned Guilhem Lavaux Guilhem Lavaux 01/May/05 02:21   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
It seems TestReference*Map fail to remove completely the strong references in
testPurgeValues because some optimization may be done for local variables by a
JIT compiler. It may be seen with CVS head of the kaffe VM. I suggest to modify
the testcases using the attached patch. It makes sure that no optimized local
variables are still on the stack. The bug is present in the head of SVN tree
(2005-04-30). It is fully reproduceable on kaffe VM (2005-04-30) with JIT3/x86.
14 years, 47 weeks, 3 days ago 18871 No Perforce job exists for this issue. 1 34689 164581 0|i0sj5r:
Commons Collections COLLECTIONS-129

[collections] Flat3Map.equals() bug

Bug Closed Major Fixed Unassigned Stanislaw Osinski Stanislaw Osinski 15/May/05 01:27   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: Windows XP
Platform: PC
Flat3Map.equals() fails a simple test:

public void testEquals()
{
Flat3Map map = new Flat3Map();
map.put("a", "testA");
map.put("b", "testB");
Flat3Map mapClone = new Flat3Map();
mapClone.put("a", "testB");
mapClone.put("b", "testA");

assertFalse("Maps should not be equal", map.equals(mapClone));
}

The code of Flat3Map.equals() is:

public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (delegateMap != null) {
return delegateMap.equals(obj);
}
if (obj instanceof Map == false) {
return false;
}
Map other = (Map) obj;
if (size != other.size()) {
return false;
}
if (size > 0) {
Object otherValue = null;
switch (size) { // drop through
case 3:
if (other.containsKey(key3) == false) {
otherValue = other.get(key3);
if (value3 == null ? otherValue != null :
!value3.equals(otherValue)) {
return false;
}
}
case 2:
if (other.containsKey(key2) == false) {
otherValue = other.get(key2);
if (value2 == null ? otherValue != null :
!value2.equals(otherValue)) {
return false;
}
}
case 1:
if (other.containsKey(key1) == false) {
otherValue = other.get(key1);
if (value1 == null ? otherValue != null :
!value1.equals(otherValue)) {
return false;
}
}
}
}
return true;
}

while it should probably be:

public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (delegateMap != null) {
return delegateMap.equals(obj);
}
if (obj instanceof Map == false) {
return false;
}
Map other = (Map) obj;
if (size != other.size()) {
return false;
}
if (size > 0) {
Object otherValue = null;
switch (size) { // drop through
case 3:
if (other.containsKey(key3)) {
otherValue = other.get(key3);
if (value3 == null ? otherValue != null :
!value3.equals(otherValue)) {
return false;
}
}
case 2:
if (other.containsKey(key2)) {
otherValue = other.get(key2);
if (value2 == null ? otherValue != null :
!value2.equals(otherValue)) {
return false;
}
}
case 1:
if (other.containsKey(key1)) {
otherValue = other.get(key1);
if (value1 == null ? otherValue != null :
!value1.equals(otherValue)) {
return false;
}
}
}
}
return true;
}

--
Stanislaw Osinski
http://www.carrot-search.com
14 years, 46 weeks, 2 days ago 18869 No Perforce job exists for this issue. 0 34917 164579 0|i0sj5b:
Commons Collections COLLECTIONS-15

[collection] ListOrderedSet doesn't implements SortedSet

Bug Closed Major Won't Fix Unassigned Marc Guillemot Marc Guillemot 03/Jun/04 17:43   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
Is it a good reason why ListOrderedSet implements Set but not SortedSet?
15 years, 43 weeks, 3 days ago 18983 No Perforce job exists for this issue. 0 29356 164693 0|i0sjun:
Commons Collections COLLECTIONS-5

[collections] Map.debug/verbosePrint Thread Safety

Bug Closed Major Fixed Unassigned Arun Thomas Arun Thomas 11/Sep/03 10:26   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
This bug records a discussion on the mailing list, and provides a forum for
continuing that discussion. I include below the content of the mailing on the
list because they raise some interesting points.

-----------------------------------------------------
From: "Arun Thomas" <Arun.Thomas@solidusnetworks.com>
-----------------------------------------------------

I recently noticed that the current implementation of the debugPrint and
verbosePrint methods in MapUtils is not thread safe - in fact, these are the
only items that are not thread safe because the indentation state for the
output is preserved in a static variable.

I think it would be fairly simple to make this thread safe, but it would
require a change to the signature of a protected member function printIndent
(PrintStream out) -> printIndent(PrintStream out, int indentDepth). I'm not
really clear as to why this method is protected rather than private (can
anyone clarify?). Does it need to be protected?

Looking forward to input from others.
-AMT

------------------------------------------------------
From: Stephen Colebourne [scolebourne@btopenworld.com]
------------------------------------------------------

The methods that call this one are synchronized to protect them, so it
should be thread-safe.

However, I would prefer them not to need to be synchronized. If you want to
submit a patch that reworks the methods that would be great.

Incompatable change?
The protected method should remain and be deprecated, as it may be used by a
MapUtils subclass (feasible but unlikely). However, I would prefer just to
go incompatable change on this one. Other committers may differ, but if they
don't I'll just commit the incompatable change.

Stephen

---------------------------------------
From: Janek Bogucki [yan@studylink.com]
---------------------------------------

These methods are synchronized so are currently thread safe.

public static synchronized void verbosePrint (...)

public static synchronized void debugPrint (...)

I would guess that a second intentional benefit of the synchronization
is to prevent overlapping invocations writing to System.out at the same
time.

-Janek

------------------------------------------------------
From: Stephen Colebourne [scolebourne@btopenworld.com]
------------------------------------------------------

I like the System.out theory. Its probably unintentional, but it true. So
only a documentation patch is required then...:-)
Stephen
16 years, 28 weeks, 3 days ago 18993 No Perforce job exists for this issue. 1 23092 164703 0|i0sjwv:
Commons Collections COLLECTIONS-66

FastArrayList, FastHashMap and FastTreeMap not thread safe

Bug Closed Major Fixed Unassigned Paul Jack Paul Jack 10/Apr/02 22:03   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: All
Platform: All
Hi,

I noticed that version 2.0 of the Commons Collections
has been released so I thought I'd browse through the
code. While doing so I noticed something about
FastArrayList, FastHashMap and FastTreeMap.

List and Map objects can return views on their contents
that can be modified. For instance, elements can be
removed from an ArrayList via its iterator(). Elements
can be removed from a map via its keySet() or its values()
collection. A TreeMap can also return a submap that can
be modified. Generally, changes on a view of a collection
are reflected in the original and vice-versa.

The problem is, with FastArrayList or FastHashMap, in "fast"
mode, if somebody tries to modify a collection view (say, a
keySet() of a FastHashMap) they will never enter the FastHashMap's
monitor. The state of the FastHashMap can become corrupted if
more than one thread attempts to modify its keySet(); and threads
attempting a fast get(Object) on a FastHashMap while another
thread modifies its keySet() may get faulty data back.

Here's the list of methods that worry me:

FastArrayList.iterator()
FastArrayList.subList(int, int)

FastHashMap.keySet()
FastHashMap.entrySet()
FastHashMap.values()

FastTreeMap.keySet()
FastTreeMap.entrySet()
FastTreeMap.values()
FastTreeMap.subMap(Object, Object)
FastTreeMap.headMap(Object)
FastTreeMap.tailMap(Object)
17 years, 34 weeks ago 18932 No Perforce job exists for this issue. 0 7924 164642 0|i0sjjb:
Commons Collections COLLECTIONS-74

[collections] Predicated Collections Throw IllegalStateException

Bug Closed Major Fixed Unassigned Nick Heudecker Nick Heudecker 01/Apr/04 12:50   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
When calling ListUtils.predicatedList(List,Predicate), the underlying class used
to create the predicated collection throws an IllegalArgumentException when it
encounters an item that failed evaluation. This is not the documented behavior
for ListUtils, and it makes that method unusable.

It probably effects the other predicated collections available in the other
Utils classes.
16 years, 4 days ago 18924 No Perforce job exists for this issue. 0 28115 164634 0|i0sjhj:
Commons Collections COLLECTIONS-106

[collections] test failures for subclasses of AbstractBidiMapDecorator and friends

Bug Closed Major Fixed Unassigned Michael Heuer Michael Heuer 30/Dec/03 05:59   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
The attached test case fails for a class that extends
AbstractOrderedBidiMapDecorator:

Testcase: testFirstKey took 0.04 sec
FAILED
expected:<foo> but was:<again>
junit.framework.AssertionFailedError: expected:<foo> but was:<again>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testFirstKey(AbstractTestOrderedBidiMap.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testFirstKeyTestcase: testLastKey took 0 sec
FAILED
expected:<all> but was:<you>
junit.framework.AssertionFailedError: expected:<all> but was:<you>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testLastKey(AbstractTestOrderedBidiMap.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testLastKeyTestcase: testNextKey took 0.05 sec
FAILED
expected:<we'll> but was:<gee>
junit.framework.AssertionFailedError: expected:<we'll> but was:<gee>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testNextKey(AbstractTestOrderedBidiMap.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testNextKeyTestcase: testPreviousKey took 0 sec
FAILED
expected:<gosh> but was:<again>
junit.framework.AssertionFailedError: expected:<gosh> but was:<again>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testPreviousKey(AbstractTestOrderedBidiMap.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testPreviousKeyTestcase: testBidiPut took 0 sec
Testcase: testBidiGetKey took 0 sec
Testcase: testBidiGetKeyInverse took 0 sec
Testcase: testBidiInverse took 0 sec
FAILED
Inverse of inverse is not equal to original. expected same:<{key1=value1,
key2=value2, key3=value3}> was not:<{key1=value1, key2=value2, key3=value3}>
junit.framework.AssertionFailedError: Inverse of inverse is not equal to
original. expected same:<{key1=value1, key2=value2, key3=value3}> was
not:<{key1=value1, key2=value2, key3=value3}>
at
org.apache.commons.collections.bidimap.AbstractTestBidiMap.testBidiInverse(AbstractTestBidiMap.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

The testBidiInverse test also fails for classes that extend
AbstractBidiMapDecorator and AbstractSortedBidiMapDecorator (not attached).
16 years, 13 weeks, 6 days ago 18892 No Perforce job exists for this issue. 1 25811 164602 0|i0sjaf:
Commons Collections COLLECTIONS-92

MultiHashMap.values() isn't backed by Map

Bug Closed Major Fixed Unassigned Paul Jack Paul Jack 03/Jun/02 15:30   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
The values() collection of MultiHashMap isn't backed by the map; changes to the
map are not reflected in a values() collection, and changes to the values()
collection are not reflected in the map.

Though MultiHashMap deliberately violates the Map contract in other ways, there
seems to be no legimate reason for it to violate the values() contract; since
values() can be implemented according to contract, it probably should be.
17 years, 19 weeks, 1 day ago 18906 No Perforce job exists for this issue. 0 9573 164616 0|i0sjdj:
Commons Collections COLLECTIONS-102

Bag interface violates Collection contract

Bug Closed Minor Fixed Unassigned Paul Jack Paul Jack 29/May/02 02:49   15/Mar/08 21:36 14/Jul/06 12:05         1 0   Operating System: All
Platform: All
The following methods as defined by the Bag interface violate their
corresponding definitions in the Collection interface:

add(Object), addAll(Collection)
The Collection interface specifies that the add method should return true if
the collection changes as a result of the call. Since a bag's size always
increases as a result of an add operation, Bag.add should always return true.
The bag interface specifies that add(Object) will only return true if the
object was not already in the unique set.

remove(Object)
The Collection interface states that only one occurrence of a given object
should be removed as a result of this method. The Bag interface specifies that
all occurrences will be removed.

removeAll(Collection)
retainAll(Collection)
containsAll(Collection)
The Collection specification does not respect cardinality for these methods;
the Bag interface does.

The add, addAll and remove methods can be fixed easily, and code relying on the
old behavior can be rewritten simply using existing Bag methods:

boolean r = bag.add(obj)

can be replaced with:

boolean r = !bag.contains(obj);
bag.add(obj)

And

boolean r = bag.remove(obj)

can be replaced with

boolean r = bag.remove(obj, bag.getCount(obj));

The existing bulk operations could be implemented with static utility methods
in CollectionUtils (or possibly BagUtils), which would allow a smooth migration
path for code that relies on the current bulk operation behavior.
13 years, 37 weeks, 4 days ago 18896 No Perforce job exists for this issue. 1 9467 164606 0|i0sjbb:
Commons Collections COLLECTIONS-131

performing get(Object) operations inside of an iteration produces an infinite loop

Bug Closed Major Fixed Unassigned Morgan Delagrange Morgan Delagrange 09/May/02 01:03   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
I just "fixed" LRUMap, which was not promoting get(Object) operations correctly.
However, now if you perform a get(Object) within an iteration of the
keySet(), it will keep promoting values to the top and producing an
infinite loop. This needs to be fixed, by making the collection throw a
ConcurrentModificationException, or by fixing the behaviour in some other way.
17 years, 43 weeks, 1 day ago 18867 No Perforce job exists for this issue. 0 8913 164577 0|i0sj4v:
Commons Collections COLLECTIONS-76

FastArrayList, FastHashMap and FastTreeMap not cross-platform

Bug Closed Major Won't Fix Unassigned Paul Jack Paul Jack 17/May/02 23:51   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
An optimizing compiler or a processor pipeline can reorder the operations that
clone the internal collection and reassign the reference to the clone. A
thread invoking a read operation can conceivably fetch a reference to a non-
fully-cloned collection, resulting in arbitrary behavior.

There seems to be no way to actually fix this bug, given the current Java
Memory Model. The code does seem to work on architectures that supply their
own more strict memory models, such as single-processor 386 systems.

At minimum, the documentation for these classes should be updated to indicate
that they are not cross-platform.

The Java Memory Model is currently under revision, and some future version of
Java will allow these classes to work by making the internal collection
reference volatile. (In the future, the volatile keyword will have better
semantics; a write to any volatile field by a thread will force a write of ALL
modifications made by that thread).

References:

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html

(These all deal with the double-checked locking algorithm, but the concepts
apply to these classes as well. Do a google search for "Bill Pugh" for more in-
depth information).
17 years, 34 weeks, 3 days ago 18922 No Perforce job exists for this issue. 0 9206 164632 0|i0sjh3:
Commons Collections COLLECTIONS-133

JavaDoc for ListUtils and FactoryUtils missing

Bug Closed Major Incomplete Unassigned Colin Colin 04/Oct/02 20:16   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
ListUtils and FactoryUtils are missing from the currently accessable commons
collection javadoc.
Maybe there are other classes missing?
17 years, 19 weeks, 1 day ago 18865 No Perforce job exists for this issue. 0 13288 164575 0|i0sj4f:
Commons Collections COLLECTIONS-83

Implementation of List with an AVLTree (TreeList)

Bug Closed Major Duplicate Unassigned Joerg Schmuecker Joerg Schmuecker 05/Feb/04 18:33   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
The existing Java List implementations are rather slow if it comes to big lists
and insertions and/or random access. To mitigate that this List is based on an
AVL-Tree and uses offsets to locate objects. The following benchmarks show the
performance compared to LinkedList and ArrayList.

add insert get
TreeList 300 501 110
ArrayList 70 20390 20
LinkedList 50 226636 279742

add - 100K times add( new Object() )
insert - 100k times add( random() * 100K, new Object() ) on a List with 100K
elements.
get - 100k times get( random() * 100k ) on a List with 200K elements.

P.S.: I will try to attach the code as a zip.
16 years, 8 weeks, 5 days ago 18915 No Perforce job exists for this issue. 0 26679 164625 0|i0sjfj:
Commons Collections COLLECTIONS-94

[collections] New feature: Extend ReferenceMap with IdentityMap functionality (WeakIdentityHashMap)

Bug Closed Major Fixed Unassigned Andy Malakov Andy Malakov 29/Jan/04 06:22   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
Hello All,

I would like to ask your opinion on providing IdentityMap features to
ReferenceMap. (I am particularly interested in WeakIdentityHashMap)


Object cache is often implemented using ReferenceMap (WeakHashMap). This class
delegates decision on when to de-cache an objects on
Java GC.

In many systems Java objects that represent database instances use database
identity: methods Object.equals(Object) and
Object.hashCode() are redefined to use database identity (identity defined in
terms of object table + object primary keys).

When traditional java.util.Map is used to implement database caches different
instances of the same database objects present a problem: instances override
each other. Class java.util.IdentityHashMap (Apache Collections 3.0:
IdentityMap) can be used to solve this problem - this approach uses
System.identityHashCode() to obtain reference hashCode and Java comparison
operator to compare keys (and values).

What I need is functionality of IdentityMap combined with WeakReference-based
keys.

Is it possible to extend ReferenceMap with an ability to use reference identity
instead of object identity? I can send you my prototype if you are interested
(it adds about ten lines of code to ReferenceMap).



Here are some links to Sun's bug parade pages that describe similar feature
request for Java's java.util.WeakHashMap:

http://developer.java.sun.com/developer/bugParade/bugs/4809420.html
http://developer.java.sun.com/developer/bugParade/bugs/4500542.html

P.S. There is a need for this feature in Apache DB-OJB project.

All the Best,
Andy
15 years, 48 weeks, 6 days ago 18904 No Perforce job exists for this issue. 2 26503 164614 0|i0sjd3:
Commons Collections COLLECTIONS-109

Bug in CollectionUtils

Bug Closed Major Fixed Unassigned Maarten Coene Maarten Coene 24/Jun/02 15:12   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
Hi,

there is a bug in CollectionUtils. If you pass in a Collection object which is
not an instance of List to the CollectionUtils.index() methods, the method
doesn't work: it just returns the given Collection instead of the i-th value in
the Collection.

I've already reported this (including a patch) to the commons-dev mailinglist,
but there was no reaction, that's why I'm trying it this way.

Here is the patch (if possible, I will also add an attachment including this
patch)

regards,
Maarten

cvs diff -u CollectionUtils.java
Index: CollectionUtils.java
===================================================================
RCS file: /home/cvspublic/jakarta-
commons/collections/src/java/org/apache/commons/collections/CollectionUtils.java
,v
retrieving revision 1.8
diff -u -r1.8 CollectionUtils.java
--- CollectionUtils.java 12 Jun 2002 03:59:15 -0000 1.8
+++ CollectionUtils.java 18 Jun 2002 12:23:34 -0000
@@ -500,6 +500,17 @@
}
}
}
+ else if(obj instanceof Collection) {
+ Iterator iterator = ((Collection)obj).iterator();
+ while(iterator.hasNext()) {
+ idx--;
+ if(idx == -1) {
+ return iterator.next();
+ } else {
+ iterator.next();
+ }
+ }
+ }
return obj;
}
17 years, 34 weeks, 3 days ago 18889 No Perforce job exists for this issue. 1 10168 164599 0|i0sj9r:
Commons Collections COLLECTIONS-10

[collections] minor javadoc fixes for OrderedIterator

Bug Closed Minor Fixed Unassigned Michael Heuer Michael Heuer 20/Jul/04 03:40   15/Mar/08 21:35 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
Minor javadoc fixes for org.apache.commons.collections.OrderedIterator.
diff -u attached.
15 years, 27 weeks, 5 days ago 18988 No Perforce job exists for this issue. 1 30191 164698 0|i0sjvr:
Commons Collections COLLECTIONS-108

[collections] [RFE] RemoveElementTransformer

Bug Closed Major Won't Fix Unassigned Guillaume Coté Guillaume Coté 05/Aug/04 01:23   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: All
Platform: All
There is transformer remove a element from a Set (modifing the original ser).
If I write proper javadoc and test case, could it be included in commons
collections.
15 years, 24 weeks, 2 days ago 18890 No Perforce job exists for this issue. 2 30477 164600 0|i0sj9z:
Commons Collections COLLECTIONS-63

[collections] compile failes with jdk 1.5 due to "enum"

Bug Closed Blocker Cannot Reproduce Unassigned Georg Müller Georg Müller 06/Aug/04 05:21   02/May/13 02:28 15/Mar/08 21:35         0 0   Operating System: other
Platform: Other
enum is a keyword in jdk 1.5
so a lot off commons (not only collections) did not compile.
A lot of variables have the name enum.
Could this be changed, please.
15 years, 27 weeks, 5 days ago 18935 No Perforce job exists for this issue. 0 30503 164645 0|i0sjjz:
Commons Collections COLLECTIONS-79

[collections] [RFE] MapToArrayTransformer

Bug Closed Major Won't Fix Unassigned Guillaume Coté Guillaume Coté 05/Aug/04 01:11   15/Mar/08 21:36 15/Mar/08 21:36         0 0   Operating System: other
Platform: Other
There is transformer received map and return a array containing the values of a
list of keys. If I write proper javadoc and test case, could it be included in
commons collections.
15 years, 24 weeks, 2 days ago 18919 No Perforce job exists for this issue. 1 30474 164629 0|i0sjgf:
Generated at Wed Mar 18 03:02:30 UTC 2020 by Subhannita Sarcar using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.